fix: tag the released ref, and record image provenance in the release - #55
Merged
Conversation
v1.4.0 claimed the git-data API sidesteps GitHub's workflow-file protection. It does not. Creating a ref at a commit whose .github/workflows differ from the default branch fails the same way over the API as over git push, reported as "Resource not accessible by integration" — the constraint is the token, not the transport, and GITHUB_TOKEN cannot hold the `workflow` scope. That condition is routine, not exotic: any CI change after the last image build triggers it, which is exactly when a release tends to happen. VirtualWindow hit it on both attempts (its build commit predates a ggshield pin and the release workflow itself). So stop encoding provenance in where the tag points. The tag marks the release point on the ref; the tag message and the release body name the build commit of every image. "Which commit is this version?" is still answerable — from the release rather than from the ref — and no repo needs a long-lived PAT to cut one. 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.
My v1.4.0 fix was wrong, and the retry proved it. I claimed the git-data API avoids GitHub's workflow-file protection. It does not — creating a ref at a commit whose
.github/workflowsdiffer from the default branch fails over the API just as it does overgit push, reported less helpfully as:The constraint is the token, not the transport, and
GITHUB_TOKENcannot hold theworkflowscope by any route.Why this is routine, not exotic
The tag has landed on each image's build commit since
v1.1.1. Any CI change merged after the last image build makes that commit's workflows differ frommain— and that is precisely the moment someone reaches for a release. VirtualWindow hit it on both attempts: its build commit predates both a ggshield pin and the release workflow itself.Verified rather than assumed:
The change
Stop encoding provenance in where the tag points. The tag marks the release point on the ref being released — whose workflows are the default branch's by definition, so the restriction can never apply. Provenance moves into content: the tag message and the release body now name the build commit of every image, e.g.
"Which commit is this version?" stays answerable, from the release instead of the ref. The guard is untouched — each image is still proven to come from this branch's history.
The alternative I rejected
A classic PAT with
workflowscope in every releasing repo. That trades a readable tag target for a long-lived credential in eight repos, in an estate already working to retire the one it has.