fix(release): name the repository for the GitHub Release job - #27
Merged
Merged
Conversation
The publish-github job downloads artifacts and never checks out the repository, so `gh release` had no git remote to infer its target from and failed with "fatal: not a git repository". This is what happened on v0.3.0: PyPI published successfully and the GitHub Release had to be created by hand. The failure is not recoverable by rerunning the job. A rerun replays the workflow definition at the tag, so fixing main does not fix a tag already pushed — and the PyPI version number is consumed by then and can never be reused, so retagging is not an option either. Set GH_REPO explicitly rather than adding a checkout: the job needs the artifacts and nothing else from the repository. 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.
What happened on v0.3.0
PyPI published successfully.
publish-githubthen failed:The job downloads artifacts and never checks out the repository, so
gh releasehad no git remote to infer its target from. The GitHub Release for v0.3.0 was created by hand from the same artifacts — sha256-verified identical to what PyPI holds.Why this could not be fixed by rerunning
Two things made it unrecoverable in place, and both are worth writing down:
maindoes nothing for a tag already pushed.0.3.0can never be reused — not by deleting the release, not by yanking — so retagging or bumping to redo the release was not an option either.The ordering introduced in #25 did its job here: PyPI-then-GitHub meant the failure left no GitHub Release falsely claiming a version was published. It just left none at all.
The fix
GH_REPO: ${{ github.repository }}on the publishing step, rather than adding a checkout — the job needs the artifacts and nothing else from the repository.A regression test asserts the job has no checkout and sets
GH_REPO, so the two cannot drift apart again. Its docstring records the incident, because the cost of rediscovering this is a hand-made release.Verification
ruffclean, full suite passes (21 tests in the release-automation module).Not verifiable before merge: the fix only exercises on the next tag push. The regression test is what stands in for that.