feat: Homebrew tap + auto-bump workflow#57
Closed
jdidion wants to merge 1 commit into
Closed
Conversation
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>
Owner
Author
|
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. |
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
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.
Summary
jdidion/homebrew-barbican. Install path:brew install jdidion/barbican/barbican.release.published-triggered workflow that auto-bumps the tap formula by opening a PR against the tap repo with updated SHA256s.README.mdto 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.quarantineon 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 verifyalready 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:
brew audit --new --strict jdidion/barbican/barbican).brew install jdidion/barbican/barbicansucceeds and places all six binaries (barbican+ 5 wrappers) on PATH.brew test jdidion/barbican/barbicanpasses — runsbarbican --version, a known-allowexplain, and a known-denyexplain(H1 classifier).barbican install.Auto-bump workflow
.github/workflows/update-homebrew-tap.ymlfires onrelease.publishedand:.sha256sidecar file.url+sha256blocks inFormula/barbican.rbvia a small Python in-place edit (regex-scoped per target — not a global search-and-replace).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 upgradeuser 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_PATwithcontents:write+pull-requests:writeonjdidion/homebrew-barbican(and nothing else). The defaultGITHUB_TOKENcan't push to a different repo.Until that secret is provisioned, the workflow will fail on the
actions/checkout@v4step. That's intentional — the failure is loud and reversible.Test plan
brew audit --new --strict jdidion/barbican/barbican— cleanbrew install jdidion/barbican/barbican— succeeds, caveats printbrew test jdidion/barbican/barbican— all three assertions passbarbican --versionreports 1.5.0 from Homebrew installpython3 -c "import yaml; yaml.safe_load(open('update-homebrew-tap.yml'))"— workflow YAML parsesworkflow_dispatchdry-run onceTAP_UPDATE_PATis provisioned — would confirm the SHA fetch + formula rewrite + PR-open path without waiting for a real releaseRoadmap pointers
🤖 Generated with Claude Code