Skip to content

release: keep unified Homebrew formula, self-updated via CI — Option B for #113 #118

Description

@arimxyer

Context

Follow-up to #113. #113 pins GoReleaser to v2.16.0 to neutralize the silent-rollforward risk. This issue captures Option B for resolving the deprecation itself — the alternative to #117. Decide between A and B; they are mutually exclusive for the Homebrew side.

The idea

GoReleaser has deprecated precompiled-binary formulae entirely (only macOS-only casks remain). Rather than migrate to casks (which drops Linux Homebrew — see #117), take Homebrew formula generation out of GoReleaser and let CI keep the formula updated. This:

  • Keeps the unified brew install reyamira/tap/pass-cli line working on both macOS AND Linux (a formula, not a cask).
  • Removes the deprecation from the equation — GoReleaser no longer touches Homebrew at all.
  • Splits responsibility: GoReleaser builds binaries + checksums + uploads; a separate CI step bumps the tap's formula url + sha256.

Can it be self-maintaining? Yes (verified)

The formula bump does not require hand-editing the .rb each release. Verified options:

  • dawidd6/action-homebrew-bump-formula — actively maintained (v7, Dec 2025; 35 releases). Explicitly supports custom third-party taps (tap: USER/REPO), auto-computes sha256, runs on release. Not a bespoke script — a maintained community action wrapping Homebrew's own tooling.
  • brew bump-formula-pr (the underlying tool) — supports --tap user/repo, auto-computes sha256, and --write-only --commit for a direct commit (no fork/PR) since the tap is our own repo.

Honest asterisks

  1. Default flow opens a fork + PR → someone merges each release. True zero-touch requires either --write-only --commit + a git push step (a small bit of glue), or auto-merge enabled on the tap. Pick a merge strategy.
  2. It's a second automation alongside GoReleaser — adds Homebrew-in-CI + a PAT with public_repo+workflow scope (we already have HOMEBREW_TAP_TOKEN for today's push). Release responsibility is split across two tools instead of one.

File-level lift (in this repo) — small

  • .goreleaser.ymlremove the brews: block. scoops: unchanged.
  • .github/workflows/release.yml (or a new update-formula.yml) — add one step running the bump action / brew bump-formula-pr against the tap (configured for direct commit).
  • docs/06-development/homebrew.md + release.md — document "we now own the formula in CI."
  • Zero user-facing install-doc churn — the brew install line is identical, so README / quick-install / manual-install / uninstall are untouched.

External tap (reyamira/homebrew-tap): Formula/pass-cli.rb becomes CI-maintained (it already exists there; it just stops being regenerated by GoReleaser and starts being bumped by the action). ~1 file, optionally + a template.

Tradeoffs

Pros: keeps Linux brew + the single unified install line; smallest in-repo footprint; no formula→cask migration; no docs churn; automation is maintained by others (Homebrew + a popular action).
Cons: a second automation with its own failure surface (Homebrew-in-CI, PAT, PR-vs-direct-commit config); release logic split across two tools; not the "native per-OS packaging" philosophy of #117.

Acceptance

On tag, the tap's pass-cli.rb is updated to the new version + sha256 with no human intervention (direct commit or auto-merge); brew install reyamira/tap/pass-cli works on macOS and Linux; goreleaser check is clean (no brews: block remains); brew is no longer referenced in .goreleaser.yml.

Verification still needed before implementing

  • End-to-end test of brew bump-formula-pr --tap <ours> --write-only --commit --no-fork + push against our own tap (the linchpin of true zero-touch — the one path not yet exercised this session).

Metadata

Metadata

Assignees

Labels

enhancementNew feature or requesthelp wantedExtra attention is needed

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions