Skip to content

Publish cortextool via a Homebrew tap #65

Description

@CharlieTLe

Problem

There is no supported way to install cortextool on macOS or Linux. The README points at the
releases page, so users download an extensionless binary, chmod +x it, and move it onto their
PATH by hand — with no upgrade path and no checksum verification.

Homebrew support existed until 9fbb6fb4, when the brews: block targeting
grafana/homebrew-grafana was dropped during the move from Grafana to cortexproject.
CHANGELOG.md:154 still references it.

Proposal

Create cortexproject/homebrew-tap (public), containing one formula, cortextool:

brew install cortexproject/tap/cortextool

Coverage from the binaries we already publish: macOS arm64, macOS x86_64, Linux x86_64.
Not benchtool (can be added later), and not Linux arm64 — we don't build it (see below).

The tap updates itself. A workflow there runs every 6 hours (plus manual dispatch), reads
our latest release, rewrites the version and the three sha256s from checksums.txt,
installs and brew tests the candidate formula on macOS arm64, macOS x86_64 and Linux
x86_64, and only commits if all three pass.

Why not GoReleaser's brews: block

It's the obvious choice, and it's a dead end:

  1. brews is deprecated — soft since v2.10, hard since v2.16
    (deprecations). The deprecated=true schema
    tag is present in the goreleaser binary.
  2. Its replacement, homebrew_casks, emits a Cask — which is macOS-only. So there is no
    forward path from brews to a formula that also serves Linux users.
  3. It needs a tar.gz archive id (the needed-for-homebrew pattern we deleted), adding ~6
    duplicate assets to every release and changing the asset list people script against.
  4. It runs inside the single existing goreleaser job, so a tap-push failure — expired
    token, deprecation turning fatal — can fail release --clean and abort a release
    mid-publish, after the Quay images are already pushed.
  5. It writes the formula blind. Nobody finds out it's broken until a user runs brew install.

Impact on this repo

Deliberately minimal — .goreleaser.yml is not modified and no release artifacts change:

  • README.md / RELEASE.md — document the install and the bump path.
  • .github/workflows/release.yml — one appended job, needs: release,
    permissions: {}, continue-on-error: true, that fires a repository_dispatch at the tap
    so bumps land in ~a minute instead of ≤6h. Optional: gated on a HOMEBREW_TAP_TOKEN
    secret; if it's absent or expired the job skips and the tap's schedule still picks the
    release up. It can never fail a release.
  • Delete the stale untracked Formula/, HOMEBREW.md, and
    scripts/update-homebrew-checksums.sh from a previous attempt.

Questions for maintainers

  1. Tap repo namecortexproject/homebrew-tap (→ brew tap cortexproject/tap), so
    non-cortex-tools formulae can live there later? Or homebrew-cortex-tools, scoped to this
    repo?
  2. Who owns it — happy for it to be a cortexproject repo with the same maintainer set?
  3. benchtool too, or start with cortextool only?
  4. Linux arm64. We only build linux/amd64, so Linux ARM users get
    Error: cortextool: The x86_64 architecture is required for this software. Worth adding
    arm64 to cortextool-linux's goarch in .goreleaser.yml as a follow-up?
  5. HOMEBREW_TAP_TOKEN. Fine to add a fine-grained PAT (Contents: write, scoped to the tap
    only) for instant bumps? Or skip it and live with the 6-hourly schedule — zero new secrets?
  6. homebrew-core eventually, instead of a tap? Realistically that needs the notability bar
    plus a build-from-source formula, and it doesn't preclude the tap now.

I have a working implementation ready to push once there's agreement on the above.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions