ci: tag-align Release Artifact workflow_dispatch path#3
Merged
Conversation
Harden the Release Artifact workflow so dispatched runs always build,
attest, and publish against the input tag's commit -- not whatever HEAD
the dispatched ref happened to be at trigger time.
What changed:
- Added an early "Resolve release tag and align working tree" step that:
- Determines RELEASE_TAG from GITHUB_REF_NAME (push) or inputs.release_tag
(dispatch).
- Verifies the tag exists, resolves its commit, and -- when the runner's
working tree is on a different commit (always the case for a dispatch
run from main) -- checks out the tag's commit so the build below
produces bytes from the tag's source state.
- Exports RELEASE_TAG and RELEASE_COMMIT to the env for downstream steps.
- Simplified the Create Release Metadata and Create GitHub Release steps
to use the resolved env vars instead of branching on GITHUB_EVENT_NAME.
- The release-create step now uses --verify-tag in both modes (defensive
against missing tags) and explicitly passes --target ${RELEASE_COMMIT}.
Why this matters:
- The previous v1.0.0 release recorded commit d23df5d (workflow's main
HEAD at dispatch time) instead of 3d6f57c (the v1.0.0 tag's commit),
because --target ${GITHUB_SHA} in dispatch mode pinned to the workflow
ref. The bundle bytes happened to match because src/ was identical
between main and the tag, but the metadata mismatch was real.
- After this change, any future dispatch of an existing tag will produce
a release with metadata, attestation, and target all anchored to the
tag's commit. Tag-push runs are unchanged in behavior.
The existing v1.0.0 release is intentionally left as-is. Re-publishing it
would require deleting the published release, which is destructive on
shared infrastructure for cosmetic gain only -- the bundle SHA matches
the consumer's pin and the consumer build will succeed.
Co-Authored-By: Claude Opus 4.7 (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.
Summary
Harden the Release Artifact workflow so dispatched runs always build, attest, and publish against the input tag's commit -- not whatever HEAD the dispatched ref happened to be at trigger time.
Background
The just-published v1.0.0 release recorded `commit: d23df5d` (the workflow's main HEAD at dispatch time) in its release.json metadata, even though the v1.0.0 tag points at `3d6f57c`. The bundle SHA matched the consumer's pin because `src/` was identical between main and the tag, but the metadata mismatch was real. This change prevents the same drift on any future re-dispatch.
What changed
Added a "Resolve release tag and align working tree" step right after checkout. It:
Simplified `Create Release Metadata` and `Create GitHub Release` to use the resolved env vars instead of branching on `GITHUB_EVENT_NAME` themselves.
release-create now always uses `--verify-tag` (defensive) plus explicit `--target ${RELEASE_COMMIT}`. Push and dispatch share one code path.
Effect on existing v1.0.0 release
Intentionally not touched. Re-publishing would require deleting a public release on shared infrastructure for cosmetic gain only — the bundle SHA matches the consumer's pin and the consumer build will succeed.
Test plan
🤖 Generated with Claude Code