Skip to content

Checksum the published tarball for Homebrew instead of waiting on npm's CDN - #118

Merged
vvillait88 merged 1 commit into
mainfrom
fix/publish-tap-checksum
Sep 21, 2026
Merged

vvillait88 merged 1 commit into
mainfrom
fix/publish-tap-checksum

Conversation

@vvillait88

@vvillait88 vvillait88 commented Sep 21, 2026

Copy link
Copy Markdown
Contributor

Summary

The publish workflow's "Update Homebrew tap" step failed on four of the last seven tag pushes (v0.5.3, v0.5.6, v0.5.7, v0.5.8). Each time it exhausted its 5-minute poll of the npm tarball URL ("tarball never became reachable in 5 minutes"), and each time a workflow_dispatch of the same tag a few minutes later succeeded. The step polled the CDN URL immediately after npm publish, so a release went red by default and needed a manual resume.

The step no longer waits on the CDN when it doesn't have to:

  • Publish: npm pack once into $RUNNER_TEMP and npm publish <that file>, so the job holds the exact bytes npm received. The build has already run, so --ignore-scripts on the pack skips nothing needed (prepublishOnly is the build, prepare is lefthook).
  • Tap: read dist.integrity from the registry metadata (which appears within seconds of a publish), and if the published file's sha512 matches, pin the formula to its sha256 directly.
  • Resumed runs (version already on npm, so no local file) download the tarball, retrying up to 10 minutes, and accept it only when it matches the same integrity. A local re-pack cannot stand in: packing the v0.5.8 tag locally gives a different sha256 (6b62...) from the published tarball (7e30...).
  • Job timeout raised from 20 to 30 minutes to cover the longer resume path.

Worked with: Varun, who asked for the fix after seeing the failure on every sweep.

Not done: nothing else in the workflow changes; npm publish, binaries, signing and the GitHub Release steps are as before.

Type of change

  • Bug fix (no breaking change)
  • New feature (no breaking change)
  • Breaking change (existing callers must update)
  • Docs, tests, or internal maintenance only

Public API

Unchanged.

Test plan

The new tap-step script ran in a node:24 container against the real v0.5.8 release, in two cases:

  • Fresh publish (the local file is the published tarball): prints "using the tarball this run published" and sha256 7e3022522ef639820b2631feb24196fa0ba60011425050906e5bc99ca3c75241, the formula's current value.
  • Resume (the local file does not match): downloads, prints "downloaded tarball matches the registry integrity", and gives the same sha256.

npm pack --pack-destination under npm 11.19.0 prints the tarball filename as its last stdout line, which the publish step relies on. The next tag push is the end-to-end check.

Checklist

  • Tests cover the new behavior, and the suite passes locally (the step logic was exercised in a container as above; the repo's unit suite does not cover workflows)
  • Lint, format, and type checks pass (no source changed)
  • Docs and README examples updated if the public surface changed (no public surface change)
  • No secrets, credentials, or personal data in the diff or the tests

…'s CDN

The tap step polled the tarball URL for five minutes right after npm
publish and failed on four of the last seven tag pushes, each fixed by a
later dispatch. The job now packs once, publishes that file, and pins the
formula to its sha256 once its sha512 matches the registry's recorded
integrity. A resumed run, which has no local copy, downloads the tarball
and checks it against the same integrity.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@vvillait88
vvillait88 merged commit b6ad17a into main Sep 21, 2026
6 checks passed
@vvillait88
vvillait88 deleted the fix/publish-tap-checksum branch September 21, 2026 16:23
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