fix(release): verify tag annotation and signature via the API - #12
Merged
Conversation
The first v0.1.0 release run rejected a perfectly good tag: annotated, signed, and reported by GitHub as verification "valid". The workflow was wrong, not the tag. `actions/checkout` materialises a tag ref as a LIGHTWEIGHT local tag pointing straight at the commit, so `git cat-file -t v0.1.0` returns `commit` inside a runner even when the real object is an annotated tag. It returns `tag` on a developer machine and the API agrees, which is why this passed every local check and only failed in CI. Both facts now come from the API, which sees the real object: - annotated-ness from .object.type on the ref - signature from .verification.verified on the tag object That also removes a latent second bug. The old code took the tag SHA from `git rev-parse`, which resolves through an annotated tag on some paths, so it could have queried the commit rather than the tag object and found no verification data at all. Nothing was published by the failed run; it stopped in the first job. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CEdTd43qLEEE5qCsL1A7gW
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Merged
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.
The
v0.1.0release run rejected a good tag. The workflow was wrong, not the tag — GitHub reports it as annotated with verification"reason": "valid".Cause
actions/checkoutmaterialises a tag ref as a lightweight local tag pointing straight at the commit. So inside a runner:while on a developer machine and via the API the same tag is
tag. That is why this passed every local check and only failed in CI.Fix
Both facts now come from the API, which sees the real object:
.object.typeon the ref.verification.verifiedon the tag objectThis also removes a latent second bug: the old code took the tag SHA from
git rev-parse, which resolves through an annotated tag on some paths, so it could have queried the commit instead of the tag object and found no verification data at all.Blast radius
None. The run stopped in the first job, so nothing was built, attested or published. npmjs still has only the
0.0.0placeholder; PyPI and Packagist have nothing.After merging
v0.1.0currently points at a commit whose workflow contains the bug, and Actions runs the workflow definition from the tagged ref — so re-running it would just fail the same way. See my note on the options; one of them needs your call because it means bypassing the immutable-tag ruleset.