Repository navigation
ci: declare the Releases permission by key (the 2026-09-30 cut 403) - #300
Closed
theogravity wants to merge 1 commit into
Closed
theogravity wants to merge 1 commit into
theogravity wants to merge 1 commit into
Conversation
…ches it The 2026-09-30 desktop cut answered POST /releases with 403 'Resource not accessible by integration' although the job's granted scopes printed Contents: write, while the same token pushed tags minutes before and the cli cut had created its release an hour earlier. That is the signature of GitHub's per-key re-mapping of GITHUB_TOKEN (the fine-grained model, rolled out org by org server-side): release operations stop riding contents: write and need releases: write. The repo declared only contents everywhere, which is right for the classic map and invisible to the new one, and it is exactly what softprops' README cannot warn about because the README still says contents: write. Declared by key at all four token-to-Releases touchpoints: both publish jobs (write), build-desktop's sidecar fetch (read), and docker-image's gh release download (read, which narrows its workflow block only). Redundant under either classic mapping, load-bearing under the other, and the next cut verifies empirically: release-cut-order.test.ts pins both publish gates and build-desktop, docker-image-chain.test.ts pins the rail.
Contributor
Author
|
Closing on a retracted theory. actionlint (and GitHub's own push-run parser, which failed this branch's release.yml while everything else on the PR ran) proves the workflow permissions schema has NO |
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
Names
releases:in the permissions block at every point the job token touches the Releases API: publish-cli/publish-desktop (write), build-desktop's stageSidecar fetch (read), docker-image'sgh release download(read). Pinned by release-cut-order.test.ts and docker-image-chain.test.ts.Why
The 2026-09-30 desktop cut died with 403
Resource not accessible by integrationon POST /releases while the job's granted scopes printedContents: write; the same token pushed tags minutes before, and an hour earlier the same workflow had created cli-server-v1.7.0's release with a byte-identical release.yml. Server-side flip, content-unchanged file, releases-only API: that is GitHub's per-key re-mapping of GITHUB_TOKEN (fine-grained model, org-by-org rollout), where releases stop riding contents. The classic map ignores the new key; the fine-grained map requires it. The next cut is the empirical verifier.Tests
bun test scripts/287/0 (fresh, not cached); both workflows parse via js-yaml.