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

Fields

No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions