wharfy 0.12.0 — publish can't ship a wrong checksum

What was wrong

A project shipping a CLI Formula next to Linux packages (or a GUI Cask) could get a Formula whose sha256 didn’t match the file its URL points at. The manifest’s archive list wasn’t restricted to the real .tar.gz archives, so a .deb / .rpm — or a .dmg — with the same os/arch could hand over its hash instead. Homebrew then rejected every artifact, and brew install failed for all users until the tap was hand-patched.

The tell: the URL ends in …_linux_amd64.tar.gz, but the recorded hash was the .rpm’s.

File at linux/amd64 sha256
wharfy_…_linux_amd64.tar.gz — what the URL serves 54b85e…
wharfy_…_linux_amd64.rpm — what got recorded 393d5c…

The fix

The manifest now takes only the actual .tar.gz archives. Packages go through apt / yum, bundles through the Cask — neither is ever folded into the Formula. Matching on .tar.gz (not just artifact kind) is the point: GoReleaser’s Linux packages carry no kind and share the archive’s os/arch, so kind alone let them slip in.

A self-check before it writes

As a backstop, publish now re-checks every manifest entry against the asset its URL points at, and refuses to write a mismatched one:

✗ publish failed at homebrew
  ! sha256 mismatch for wharfy_0.12.0_linux_amd64.tar.gz:
    manifest records 393d5c… but the uploaded artifact is 54b85e…

A wrong checksum stops publish now, instead of reaching users. This is exactly how 0.12.0 caught the bug on itself.

Also in 0.12.0

wharfy release now records the script channel it already uploads, so a fresh install.sh no longer shows as drifted in wharfy status.

Getting it

brew upgrade wharfy / scoop update wharfy / go install github.com/ShiroDoromoto/wharfy/cmd/wharfy@latest. On Linux, from the apt / yum repo.