ci(release): bump the Homebrew cask automatically on release - #53
Merged
Conversation
Hashes the .dmg attached to a release, rewrites version and sha256 in the tap's cask, then opens an auto-merging pull request. --dry-run stops after the rewrite so the substitution can be rehearsed against a tap checkout.
Until now the cask was bumped by hand, so `brew upgrade --cask notchbar` served the previous version for as long as that took. The job runs after the release exists, since the sha256 has to come from the published .dmg. The PR is authored with a PAT rather than GITHUB_TOKEN: a GITHUB_TOKEN PR does not trigger the tap's test-bot, which is the check auto-merge waits on.
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
Nothing tells an installed NotchBar that a newer version exists, and the one channel that could update itself — Homebrew — was bumped by hand. Between a release and that manual bump,
brew upgrade --cask notchbarwas a no-op: users stayed on the old version without any signal. Someone is running 0.1.0 today.This closes the Homebrew half of the problem. The in-app update check is a separate piece of work.
What
scripts/bump-cask.sh VERSION TAP_DIR [--dry-run]— downloads the .dmg attached to the release, computes its sha256 on the exact bytes Homebrew will fetch, rewritesversionandsha256in the tap's cask, then pushes a branch and opens a pull request with auto-merge on. It is idempotent (a cask already on that version and hash exits 0) and refuses to open a PR if either substitution silently missed.bump-caskjob inrelease.yml, running after the release is published, onubuntu-latestwith read-only permissions on this repo — every write to the tap goes throughTAP_TOKEN.The PR is authored with a PAT rather than
GITHUB_TOKEN, because aGITHUB_TOKENPR does not trigger the tap'sbrew test-bot— which is exactly the check auto-merge has to wait on.Repository setup already applied on Periicles/homebrew-tap
mainruleset requiring a pull request and a greentest-botcheck, blocking deletion and force-push. Nothing lands on the tap unmerged or unchecked, including the bot's own bump.Still needed before the next tag
Create the
TAP_TOKENrepository secret here: a fine-grained PAT scoped toPeriicles/homebrew-tapwith contents, pull requests and issues write access (issues covers the assignee). Without it thebump-caskjob fails with an explicit message — the release itself still publishes.Verification
The computed hash matches the one the live cask already carries for 0.3.0, so the bump would have reproduced the current tap exactly. Also exercised: idempotent re-run against the real tap (exit 0, no change), a malformed version, a directory that is not a tap, and a version with no release (curl 404). Workflow parsed with a YAML loader; no Swift code is touched, so the test suite is unaffected.