Skip to content

feat: Homebrew tap + auto-bump workflow#57

Closed
jdidion wants to merge 1 commit into
mainfrom
feat/homebrew-tap
Closed

feat: Homebrew tap + auto-bump workflow#57
jdidion wants to merge 1 commit into
mainfrom
feat/homebrew-tap

Conversation

@jdidion
Copy link
Copy Markdown
Owner

@jdidion jdidion commented May 8, 2026

Note: This MR was largely generated by Claude and has not been completely reviewed by me (the human). You should feel free to defer your review until this warning has been removed.

Summary

  • Publish Barbican via a Homebrew tap at jdidion/homebrew-barbican. Install path: brew install jdidion/barbican/barbican.
  • Add a release.published-triggered workflow that auto-bumps the tap formula by opening a PR against the tap repo with updated SHA256s.
  • Update README.md to promote Homebrew as the preferred install path; direct-download remains documented as a fallback.

No code changes in crates/barbican/. No version bump (the release artifacts are unchanged — only the distribution channel is new).

Why

Direct-download macOS tarballs currently trigger Apple Gatekeeper warnings ("cannot be opened because the developer cannot be verified") because Barbican isn't Apple-codesigned yet. Homebrew strips com.apple.quarantine on install, so the tap is the friction-free path until an Apple Developer ID codesign lands (tracked separately in #55). Windows Authenticode signing + Windows builds tracked in #56.

The tap downloads the same tarballs gh attestation verify already validates; users get the same bytes either way. The formula pins a SHA256 per target.

Tap repo state

The tap is already live with the initial 1.5.0 formula committed and verified end-to-end:

  • Formula audits clean (brew audit --new --strict jdidion/barbican/barbican).
  • brew install jdidion/barbican/barbican succeeds and places all six binaries (barbican + 5 wrappers) on PATH.
  • brew test jdidion/barbican/barbican passes — runs barbican --version, a known-allow explain, and a known-deny explain (H1 classifier).
  • Caveats block prints a clear next-step message pointing users at barbican install.

Auto-bump workflow

.github/workflows/update-homebrew-tap.yml fires on release.published and:

  1. Pulls the version from the release tag.
  2. Fetches each target's SHA256 from the release's .sha256 sidecar file.
  3. Rewrites the four url + sha256 blocks in Formula/barbican.rb via a small Python in-place edit (regex-scoped per target — not a global search-and-replace).
  4. Opens a PR on the tap repo titled bump: barbican <version> for manual review before merging.

The PR-not-push flow was a deliberate choice: a botched release that ships to every brew upgrade user has a much wider blast radius than one that needs a manual merge first.

Prerequisite for the workflow to actually run

A fine-grained PAT stored as secrets.TAP_UPDATE_PAT with contents:write + pull-requests:write on jdidion/homebrew-barbican (and nothing else). The default GITHUB_TOKEN can't push to a different repo.

Until that secret is provisioned, the workflow will fail on the actions/checkout@v4 step. That's intentional — the failure is loud and reversible.

Test plan

  • brew audit --new --strict jdidion/barbican/barbican — clean
  • brew install jdidion/barbican/barbican — succeeds, caveats print
  • brew test jdidion/barbican/barbican — all three assertions pass
  • barbican --version reports 1.5.0 from Homebrew install
  • python3 -c "import yaml; yaml.safe_load(open('update-homebrew-tap.yml'))" — workflow YAML parses
  • workflow_dispatch dry-run once TAP_UPDATE_PAT is provisioned — would confirm the SHA fetch + formula rewrite + PR-open path without waiting for a real release

Roadmap pointers

🤖 Generated with Claude Code

Publish Barbican via `brew install jdidion/barbican/barbican` from the
new jdidion/homebrew-barbican tap. The tap's formula pins a SHA256
per target (aarch64/x86_64 × apple-darwin/unknown-linux-gnu) against
the existing GitHub release tarballs; users get the same bytes the
`gh attestation verify` path validates today.

Why: direct-download macOS tarballs trigger Gatekeeper warnings until
Barbican ships with an Apple Developer ID codesign (tracked in #55).
Homebrew strips `com.apple.quarantine` on install, so the tap is the
friction-free install path in the meantime — and the standard path
most organizations use for Rust CLIs regardless.

This PR adds:
- `.github/workflows/update-homebrew-tap.yml` — opens a PR on the tap
  repo whenever a release is published, pulling SHA256s from the
  release's `.sha256` sidecar files. Requires a TAP_UPDATE_PAT secret
  with contents:write + pull-requests:write on jdidion/homebrew-barbican.
- README `Install` section updated to promote `brew install` as the
  preferred path; direct-download remains documented as a fallback.
- CHANGELOG `[Unreleased]` entry describing the tap + pointers to the
  codesign follow-ups (#55 Apple, #56 Windows).

Tap repo already exists at https://github.com/jdidion/homebrew-barbican
with the initial 1.5.0 formula committed; `brew install` + `brew audit
--new --strict` + `brew test` all pass locally.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@jdidion jdidion marked this pull request as ready for review May 12, 2026 16:15
@jdidion
Copy link
Copy Markdown
Owner Author

jdidion commented May 12, 2026

Superseded. The Homebrew tap + auto-bump workflow landed via a different branch track: the tap workflow went in on 2026-05-08 (#62-ish era), auto-merge and the release-workflow-dispatch integration landed in #71 as part of closing the #70 release-ordering race, and the tap has been live in production for the 1.5.0 -> 1.6.0 release range (formula bumps #5, #6, #7, #8 in jdidion/homebrew-barbican). Main is strictly ahead — the workflow on this PR is 62 lines shorter than what's on main today. Nothing to salvage. Deleting the branch.

@jdidion jdidion closed this May 12, 2026
@jdidion jdidion deleted the feat/homebrew-tap branch May 12, 2026 16:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant