Homebrew publisher ships metadata stubs again: Forgejo 15 ignores Accept on the download route #1493

New issue

Closed

opened 2026-07-21 04:47:19 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-07-21 04:47:19 +00:00

Member

Problem

The Homebrew publisher regressed under Forgejo 15.0.2: the Accept: application/octet-stream header no longer selects the asset body on the releases/download/<tag>/<asset> route, so the ward#1472 fix is inert. Live evidence from tonight's v0.781.0 release:

releases/download/v0.781.0/ward-darwin-arm64 returns the same 280-byte asset-metadata JSON with and without the Accept header (identical sha both ways).
The generated formula carries all six header stanzas from ward#1472 and it still hashed and installed metadata - brew upgrade landed a 280-byte non-executable "binary" on a real machine tonight. The install was repaired by hand-fetching the true asset.
The only byte-serving path is the browser_download_url in the metadata (/attachments/<uuid>), which serves the raw asset anonymously. The real binary fetched that way matches the published .sha256.

Timing note: the Forgejo pod restarted about ten days ago, which lines up with when the release pipeline first reddened - this route change was likely the first domino behind the ward#1328 streak.

Done when

The bump-tap-formula generator resolves each asset's browser_download_url and emits those URLs in the formula, dropping the Accept-header stanzas.
The hash step hashes the bytes fetched from browser_download_url, never the download-route response.
Release contract tests model the new Forgejo behavior: the mock serves metadata on the download route regardless of Accept, and the emitted formula must carry attachment URLs whose hashes match the served bodies.
The Scoop manifest generator gets the same treatment (same exposure, best-effort policy unchanged).

Context

Supersedes the ward#1472 approach for the current Forgejo (evidence comment posted there tonight). Overlaps the stage-2 lang-go migration in #1492 - both touch the same release.yml jobs, sequencing free.

Filed by Claude Code during the release-pipeline repair session with Kai.

## Problem The Homebrew publisher regressed under Forgejo 15.0.2: the `Accept: application/octet-stream` header no longer selects the asset body on the `releases/download/<tag>/<asset>` route, so the ward#1472 fix is inert. Live evidence from tonight's v0.781.0 release: * `releases/download/v0.781.0/ward-darwin-arm64` returns the same 280-byte asset-metadata JSON with and without the Accept header (identical sha both ways). * The generated formula carries all six header stanzas from ward#1472 and it still hashed and installed metadata - `brew upgrade` landed a 280-byte non-executable "binary" on a real machine tonight. The install was repaired by hand-fetching the true asset. * The only byte-serving path is the `browser_download_url` in the metadata (`/attachments/<uuid>`), which serves the raw asset anonymously. The real binary fetched that way matches the published `.sha256`. Timing note: the Forgejo pod restarted about ten days ago, which lines up with when the release pipeline first reddened - this route change was likely the first domino behind the ward#1328 streak. ## Done when * The bump-tap-formula generator resolves each asset's `browser_download_url` and emits those URLs in the formula, dropping the Accept-header stanzas. * The hash step hashes the bytes fetched from `browser_download_url`, never the download-route response. * Release contract tests model the new Forgejo behavior: the mock serves metadata on the download route regardless of Accept, and the emitted formula must carry attachment URLs whose hashes match the served bodies. * The Scoop manifest generator gets the same treatment (same exposure, best-effort policy unchanged). ## Context Supersedes the ward#1472 approach for the current Forgejo (evidence comment posted there tonight). Overlaps the stage-2 lang-go migration in #1492 - both touch the same release.yml jobs, sequencing free. Filed by Claude Code during the release-pipeline repair session with Kai.

coilyco-ops referenced this issue from a commit

2026-07-21 05:06:46 +00:00

fix(release): resolve asset byte URLs for brew and scoop (closes #1493)

coilyco-ops closed this issue

2026-07-21 05:06:46 +00:00

coilyco-ops referenced this issue from a commit

2026-07-21 05:12:21 +00:00

fix(release): heredoc-indent the asset_url python bodies

coilyco-ops referenced this issue from a commit

2026-07-21 05:24:01 +00:00

fix(release): hop-resolve asset URLs; guard hashes against SHA256SUMS

coilyco-ops referenced this issue