Releasing (maintainer)

Run Actions > Promote test and release > Run workflow when test is ready to ship. It rebases test onto main, checks that <Version> in SteamCmdHelper.csproj has a ## <version> section in CHANGELOG.md and no tag yet, runs the tests, then in one push fast-forwards main, tags it v<version> and resets test to the new main. The tag starts the release below. It never changes the version: bump it on test first. Optional inputs: version stops the run if test declares a different one, and dry run does every check and the tests but pushes nothing. If test does not rebase cleanly, or someone pushes to test during the run, nothing is pushed.

Merging a test -> main pull request instead also works, but with Automatically delete head branches turned on GitHub deletes test afterwards. .github/workflows/keep-test-branch.yml then recreates it at the new main. To stop the deletion outright, add a ruleset for test under Settings > Rules > Rulesets with Restrict deletions on.

It needs a RELEASE_TOKEN secret: a fine-grained personal access token for this repository with Contents and Workflows set to read and write. The built-in Actions token cannot push commits that change workflow files, and a tag it pushes does not start other workflows. If main has branch protection or a ruleset, the token's owner must be allowed to push to it directly.

Pushing a vX.Y.Z tag by hand also works. Either way, the tag runs .github/workflows/release.yml, which tests, builds, signs (when set up), and publishes the release. After a non-prerelease it also:

• opens a pull request pointing bucket/steamcmdhelper.json (the Scoop manifest) at the new exe and its SHA-256. This needs Settings > Actions > General > Allow GitHub Actions to create and approve pull requests.
• sends the new version to winget with wingetcreate, once a WINGET_TOKEN secret exists (a classic GitHub token with public_repo). The package must be in winget-pkgs first: submit the manifests in packaging/winget once by hand (wingetcreate submit packaging/winget).

#Code signing (maintainer)

Unsigned exes trip SmartScreen and some antivirus. The release signs the exe, and the app's exe and dll in the framework-dependent zip, through SignPath (free for open-source projects) when these are set:

• secret SIGNPATH_API_TOKEN (a SignPath CI user with submitter rights on the project)
• variable SIGNPATH_ORGANIZATION_ID
• optional variables SIGNPATH_PROJECT_SLUG (default SteamCMDHelper) and SIGNPATH_POLICY_SLUG (default release-signing)

The SignPath project's artifact configuration is packaging/signpath/artifact-configuration.xml: it signs only files whose product name is SteamCMD Helper and whose product version is the release's version, which the workflow passes in. The project needs the GitHub trusted build system linked to it. Each release waits up to an hour for the signing request to be approved in SignPath; if nobody approves it, the release run fails and nothing is published. Without the secret, releases are built unsigned as before.

Releases are not signed yet. SignPath Foundation requires a "Code signing policy" section in this README (who commits, who approves releases, and the privacy notes above), so add one back when applying; the release notes link to it once SIGNPATH_API_TOKEN exists.