ci: drive releases from published GitHub Releases - #34
Merged
Conversation
Releases were triggered by pushing a vSEMVER tag, and the workflow then refused to run unless package.json already matched — so tagging a commit that had not been bumped (which is what a GitHub Release does) always failed. Publishing a GitHub Release is now the trigger. The workflow derives the version from the release tag, writes it into package.json and src/version.ts, commits that to main, and moves the tag onto the bump commit before publishing. src/version.ts had drifted to 2.0.8 against a package.json of 0.0.5, so the X-Assembly-SDK-Version header was wrong on every request. It is now generated by the same step and pinned by a test. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The version now comes from the GitHub Release tag, so there is nothing left for bumpp to compute. Leaving the script in place would push a tag that triggers nothing. Co-Authored-By: Claude Opus 5 (1M context) <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
1 participant
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.
Releases were triggered by pushing a
v*tag, and the workflow then refused to run unlesspackage.jsonalready matched the tag — so creating a GitHub Release (which tags an existing, unbumped commit) always failed the verify step, as in run 32134413590.Publishing a GitHub Release is now the trigger. The workflow reads the version from the release tag, writes it into
package.jsonandsrc/version.ts, commits that to main, moves the tag onto the bump commit, then builds and publishes to npm.Blocker: the existing
v0.0.6tag points at an unbumped commit and must be deleted before cutting v0.0.6, otherwise the release reuses it and the retag lands on the wrong commit.v0.05is a typo tag and can go too.What to look at:
.github/workflows/release.yml— the bump step pushes to main with the defaultGITHUB_TOKEN; main is currently unprotected, so this works, but adding a required-review rule later will break it. It also force-moves the release tag.src/version.ts— was hardcoded at2.0.8against apackage.jsonof0.0.5, soX-Assembly-SDK-Versionhas been wrong on every request. Now generated by the release step and pinned bytests/version.test.ts.ref: main, so the published artifact is main's HEAD, not necessarily the commit the release was cut from. Fine when releases come off main; worth knowing.bumppand thereleasescript are removed — the tag decides the version now, so bumpp has nothing to compute and running it would only push a tag that triggers nothing. Also dropped thechangelogithubstep, since the release body you write in the UI is now the changelog and changelogithub would overwrite it.Verified:
bun run test(196 pass),vp checkclean, workflow YAML parses. The workflow itself is unverified until a real release runs.🤖 Generated with Claude Code