Skip to content

fix(release): publish release before pushing bump commit - #100

Merged
5uck1ess merged 1 commit into
mainfrom
fix/release-bump-race
May 19, 2026
Merged

fix(release): publish release before pushing bump commit#100
5uck1ess merged 1 commit into
mainfrom
fix/release-bump-race

Conversation

@5uck1ess

Copy link
Copy Markdown
Owner

Summary

Closes the ~80-second race window between version bump and asset upload that breaks devkit MCP for any CC session opened immediately after a merge.

Today's flow:

  1. Version job pushes bump to vX.Y.Zmain (CC users start syncing the new plugin.json)
  2. Tag + draft release created (assets URLs return 404 to unauthenticated downloads)
  3. Binaries built in parallel (~60-80s)
  4. Checksums + un-draft → release goes public

If CC syncs the plugin between steps 1 and 4, bin/devkit reads plugin.json at the new version, tries to download devkit-darwin-arm64 from the draft release, gets 404, and CC caches the MCP startup failure until restart. This is what just bit us on v2.1.30 (commit at 15:06:05Z, release published at 15:07:27Z — 82s exposure).

New flow:

  1. Determine target version (no push)
  2. Tag the PR-merge commit + create draft release
  3. Build binaries (matrix unchanged)
  4. Checksums + un-draft
  5. Only now push the bump to vX.Y.Z commit to main

plugin.json on main advertises the new version only after the matching release is fully live. Wrapper's first-run download is guaranteed to find assets.

Notes

  • Tag points to the PR-merge commit (not the bump commit). For auto-bumps the tagged tree has plugin.json one version behind the tag name (the bump itself lands in step 5). For manual bumps the merge commit already carries the new plugin.json, so the tag content matches.
  • Bump failures no longer trigger cleanup. By the time bump runs, the release is published; tearing it down would create a much bigger inconsistency than a one-version-behind plugin.json. The next merge's auto-bump walks forward from the latest tag and self-recovers.
  • Manual-bump PRs still have a race (plugin.json updated in the PR itself, before the workflow runs). Out of scope; would need a separate "manual bumps must wait for release" enforcement.

Test plan

  • Open a trivial follow-up PR after this merges and verify: (a) tag lands on the PR-merge commit, (b) release publishes before the next bump commit appears on main, (c) bin/devkit first-run download succeeds on a clean install of the new version.
  • Confirm a manual-bump path (open a PR that hand-edits plugin.json version) still tags the merge commit and skips the auto-bump step.
  • Confirm cleanup-on-failure still fires when binaries step fails (delete a build target temporarily to test) — release tag + draft are removed.

The current release workflow pushes the `bump to vX.Y.Z` commit to main
*before* the matching GitHub release is published. During the ~80s build
window the release is still a draft, so asset URLs return 404 to
unauthenticated downloads — the `bin/devkit` wrapper's first-run engine
download then fails and CC caches the MCP startup failure until restart.

Reorder so the bump commit lands only after binaries are uploaded and
the release is un-drafted. The release tag now points to the PR-merge
commit (matters only for auto-bumps — manual bumps already have the new
plugin.json in the merge commit). Cleanup-on-failure intentionally
excludes bump failures: the release is already published by then, so
artifacts must stay; the next merge's auto-bump walks forward from the
latest tag and self-recovers if a single bump push fails.
@5uck1ess
5uck1ess merged commit 2ff84a5 into main May 19, 2026
6 checks passed
@5uck1ess
5uck1ess deleted the fix/release-bump-race branch May 19, 2026 15:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant