ci: publish the Homebrew formula to skyoo2003/homebrew-tap - #121
Merged
Conversation
devcloud was never available via `brew install`, even though the release already builds every archive the formula needs. Add a `brews` section that writes Formula/devcloud.rb into skyoo2003/homebrew-tap on each tag. The tap lives in another repository, so the job's own GITHUB_TOKEN cannot write to it. Instead of a long-lived PAT, mint a GitHub App installation token that is scoped to homebrew-tap alone and expires with the job. The dry run skips minting it, since nothing is published there. The formula test only asserts the flag usage text: devcloud is a long-running server with no subcommands, so anything else would hang. While here, migrate archives to `formats:`, which `goreleaser check` has flagged as deprecated since v2.6.
Contributor
Reviewer's GuideThis PR updates the GoReleaser configuration and the release GitHub Actions workflow to publish a Homebrew formula for devcloud to the skyoo2003/homebrew-tap repository, using a short-lived GitHub App token and modern archive configuration options. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
Contributor
There was a problem hiding this comment.
Hey - I've left some high level feedback:
- The tap repository owner/name (
skyoo2003/homebrew-tap) is hardcoded in both.goreleaser.yamland the workflow; consider centralizing these values (e.g., via env vars or workflow inputs) to avoid drift if they ever change. - In the release workflow,
HOMEBREW_TAP_TOKENis always set fromsteps.tap_token.outputs.tokeneven when the minting step is skipped on dry runs; if GoReleaser ever starts validating this token, you may want to guard the env assignment with the samedry_runcondition or provide a safe default.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The tap repository owner/name (`skyoo2003/homebrew-tap`) is hardcoded in both `.goreleaser.yaml` and the workflow; consider centralizing these values (e.g., via env vars or workflow inputs) to avoid drift if they ever change.
- In the release workflow, `HOMEBREW_TAP_TOKEN` is always set from `steps.tap_token.outputs.token` even when the minting step is skipped on dry runs; if GoReleaser ever starts validating this token, you may want to guard the env assignment with the same `dry_run` condition or provide a safe default.Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
The tap owner and repository name were spelled out in both .goreleaser.yaml and the release workflow, so a move would have to be caught in two places. Declare them once as workflow-level env vars -- the owner from github.repository_owner -- and let both the token-minting step and the brews section read them. HOMEBREW_TAP_TOKEN keeps its unconditional assignment: the homebrew pipe renders the formula even under --snapshot, and an unset variable fails the template outright rather than resolving empty. A dry run gets a placeholder instead, which nothing ever uses because --snapshot publishes nothing.
skyoo2003
added a commit
to skyoo2003/homebrew-tap
that referenced
this pull request
Jul 30, 2026
Both projects are only now wired up to publish here (skyoo2003/acor#181, skyoo2003/devcloud#121), so their current releases would otherwise stay uninstallable until the next tag. Every sha256 comes from the CHECKSUMS asset of the published release, not from a local build. The files match GoReleaser's own template byte for byte apart from the version, URLs and checksums, so the first automated release overwrites them with a diff of nothing else.
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
brew install skyoo2003/tap/devclouddoes not work today — the tap only carrieskvs. The release already builds every archive a formula needs, so this only adds the publishing step.What
.goreleaser.yaml:brewssection writingFormula/devcloud.rbtoskyoo2003/homebrew-tap.release.yml: mint the cross-repo token withactions/create-github-app-token, scoped tohomebrew-taponly and expiring with the job — no long-lived PAT (see Drop QEMU from release, retire GH_PAT, close review gaps kvs#228). Skipped on a dry run, which publishes nothing.archives:format:→formats:, deprecated since GoReleaser v2.6.Requires repository secrets
TAP_APP_IDandTAP_APP_PRIVATE_KEY.Verified locally
goreleaser release --snapshot --skip=dockergeneratesdist/homebrew/devcloud.rbwith the correct darwin/linux amd64+arm64 matrix, and succeeds withoutHOMEBREW_TAP_TOKEN— so thedry_run: truepath stays green without the secret.ruby -con the generated formula: syntax OK.test doassertion matches reality:devcloud -hprints the-configflag and exits 0. It deliberately does not start the server — devcloud has no subcommands, so any other invocation would hang the test.Note
brewsis deprecated (removal in GoReleaser v3);homebrew_casksis not a drop-in replacement because casks are macOS-only. At v3 this moves to a generator in the tap repository.