fix(release): watch the run for this tag, and let a re-run converge - #27
Merged
Conversation
Two defects in the same path, both found by shipping v0.4.1. `make ship` is tag-release then release-watch, and the tag push returns before GitHub has created the workflow run — so `gh run list --limit 1` returned the PREVIOUS release. v0.4.1 was reported as failed against a run that had failed the night before, while the real release went on to succeed on every job. A watcher that can report the wrong run is worse than no watcher: the failure it invents is indistinguishable from a real one, and the first instinct is to go fix a release that is already fine. Selecting by tag is exact — a tag-triggered run carries the tag in headBranch — and a bounded wait covers creation latency, turning "not created yet" into a clear error instead of an empty run ID. Second, github-release could not survive a re-run: `gh release create` refuses an existing tag, so a re-dispatch died there every time, after build and publish had both succeeded. workflow_dispatch was added to this workflow so a release could be re-driven through a webhook outage, which the old step quietly took back. It now edits the release and clobbers the asset when one exists. Verified both watcher paths against real runs: VERSION=0.4.1 selects 31137565770 and exits 0; VERSION=9.9.9 errors after the 60s wait naming the query to run by hand. 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.
Two defects in the release path, both surfaced by shipping v0.4.1 an hour ago.
make shipreported a failure that wasn't oneshipistag-releasethenrelease-watch, and the tag push returns beforeGitHub has created the workflow run — so
gh run list --limit 1handed backthe previous release. v0.4.1 was reported as failed against a run that had
failed the night before, while the real release succeeded on every job.
A watcher that can report the wrong run is worse than no watcher: the failure
it invents is indistinguishable from a real one, and the first instinct is to
go fix a release that is already fine.
Now selects by tag (
--branch "v$VERSION"— a tag-triggered run carries thetag in
headBranch) and waits up to 60s for the run to exist, so "not createdyet" becomes a clear error instead of an empty run ID.
A re-dispatched release always died at the last step
gh release createrefuses an existing tag, so re-driving a release that hadalready got as far as publishing failed on
a release with the same tag name already exists— afterbuildandpublishhad both succeeded, which is themost confusing place to stop.
workflow_dispatchwas added to this workflowprecisely so a release could be re-driven through a webhook outage; a final
step that cannot survive a second run takes that back. It now edits the
release and clobbers the asset when one exists.
Verification
Both watcher paths run against real data:
make release-watch VERSION=0.4.1→ selects31137565770, exits 0.make release-watch VERSION=9.9.9→ errors after the 60s wait, naming thegh run listquery to run by hand.make lintclean.Not done here
release-watch.shin just-makeit and doppler already solves this morethoroughly — and the two copies have drifted from each other (doppler's adds
C-tarball assertions and a more precise post-publish exclusion). Folding them
into one script here, where bash scripts belong, is the right end state, but
both repos have work in flight; this stays a local fix.
🤖 Generated with Claude Code