ci: validate the tap token before publishing anything - #5
Merged
Conversation
Both v0.8.1 and v0.8.2 published complete releases and then failed at the cask with `401 Bad credentials` on mondaycom/homebrew-tap. Because releases here are immutable and the cask pipe runs after the release pipe, neither could be repaired -- each attempt cost a version to discover the same broken credential. Check the token before the release exists. If it cannot read the tap, or can read but not push, the job stops in seconds having published nothing, so fixing the secret and re-running is enough; no new tag needed. gh puts a one-line summary on stderr and the JSON body on stdout, so the annotation reports stderr -- 401 distinguishes an invalid or truncated token from a 404 for a token with no access to the repository. Bumps flake.nix to 0.8.3, which the preceding version guard requires. Co-Authored-By: Claude Opus 5 <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.
Why
v0.8.1 and v0.8.2 both published complete, correct releases and then failed at the same place:
HOMEBREW_TAP_TOKENis now set as a secret, so the value itself is what GitHub is rejecting —401 Bad credentialsmeans the credential is invalid outright (expired, revoked, or pasted incompletely), as distinct from a404for a valid token lacking access to that repo.The expensive part isn't the bad token, it's that discovering it costs a version each time. Releases here are immutable and the cask pipe runs after the release pipe, so by the time the cask fails there's a published release that can never receive one, and re-running is refused. Two versions burned to learn the same fact.
What this does
Checks the token before the release exists. On failure the job stops in seconds having published nothing — so fixing the secret and re-running is enough, with no new tag. It also catches a token that can read the tap but not push to it, which would otherwise fail later at exactly the same unrecoverable point.
Also bumps
flake.nixto0.8.3, which the version guard from #4 requires.Verification
Exercised all four paths locally:
HOMEBREW_TAP_TOKEN is not set.cannot read mondaycom/homebrew-tap -- gh: Bad credentials (HTTP 401)cannot read ... -- gh: Not Found (HTTP 404)tap token can push to mondaycom/homebrew-tapThe invalid case reproduces the exact error the two releases hit.
ghprints its one-line summary to stderr and the raw JSON body to stdout, so the annotation reads stderr — reading stdout instead yields a useless{.nix build .#mcli→mcli version 0.8.3.Before tagging v0.8.3
The token still needs fixing — this PR only ensures a bad one fails cheaply. Worth checking it hasn't expired and that it grants Contents: read and write on
mondaycom/homebrew-tap; if it's fine-grained, an org-owned repo may also need approval from an org admin.🤖 Generated with Claude Code