Repository navigation
CI: build every pull request, and release on merge - #9
Merged
Merged
Conversation
The build ran only by hand from the Actions tab, and a release was a draft made from a typed version, published by hand. Now it runs for every pull request and every push to main, and a push to main whose version_string has no tag yet (a PR that bumps it) tags that commit and publishes the release, with notes from the PRs since the last one. A push that leaves the version alone only builds, which also keeps main's compiler caches warm for the pull requests after it. Pushing a v* tag still releases. A pull request from a fork gets no secrets, so the microcode secret still never reaches code from forks: such a build lays zeros where the audio microcode goes. It compiles, links and packages all three as a release does, plays no sound, and uploads nothing. Main's runs queue rather than cancel, so a release is never cut off halfway. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The build workflow runs for every pull request and every push to main now, and merging a PR that bumps
version_stringpublishes that version's release. This PR bumps it to 1.6.0, so merging it releases 1.6.0 with #7 and #8's widescreen intro, menus, attract demos and HUD in it.version_stringhas no tag yet builds, tags that commitv<version>and publishes the release with all three packages, its notes generated from the PRs since the last tag. Nothing is tagged until all three have built, so a failed release can be re-run.v*tag still releases, and the Actions tab's run still builds any branch. The version input is gone: the version isversion_string.The microcode secret still never reaches code from forks: GitHub gives a
pull_requestrun from a fork no secrets. Such a run lays zeros where the audio microcode goes. It compiles, links and packages everything a release does, but plays no sound, so it uploads no artifacts. A PR from a branch in this repo gets the secret and real packages.Tested: actionlint passes on the workflow. This PR's own run is a fork's, so it built all three with zeros for the microcode, skipped uploading and skipped the release. The release path ran on a fork of this repo with its own copy of the secret: pushing these two commits to its main built all three, tagged
v1.6.0and published (not drafted) a release with the macOS, Linux and Windows packages, in 45 minutes from cold caches. The macOS jobs had to be re-run twice during GitHub's Actions incident this afternoon, when no macOS runner picked them up. Nothing here changes what a build compiles: the only code change is the version.Written by AI (Claude).
🤖 Generated with Claude Code