The builds table only ever existed inside a GitHub release body. Emit the
same rows as a tiny standalone page in R2, so a build is readable straight
from the download origin:
releases/<channel>/index.html latest stable / canary builds, every
variant, replaced by each tag run
releases/commit/<sha>/index.html every expected binary of one commit
build, built or not
scripts/render-builds-table.py keeps ONE row set per mode and renders it
into two sinks (release body markdown, page HTML), so the page can never
list different artifacts than the release. A channel page is a mutable
pointer written from a per-tag job, so it records its release tag and the
writer compares that against scripts/releases/semver.py before replacing:
re-running an older tag cannot regress a newer channel page.
Pages need two registrations to be usable: `.html` maps to
text/html; charset=utf-8 in release-content-types.json (unregistered, R2
serves the object as an octet-stream download) and to no-store in
r2.cache_control_for (the page is a pointer, not an artifact). Page keys
and public URLs come from new r2 layout helpers, shared with
`release.py --build-commit`, which now prints the commit page URL before
dispatching. No workflow change: the existing renderer jobs already carry
the R2 credentials.
Verified: 76 tests over the renderer/release/transport files, including a
loopback R2 PUT proving the page object lands as text/html with no-store.
14 lines
397 B
JSON
14 lines
397 B
JSON
{
|
|
".appinstaller": "application/appinstaller",
|
|
".html": "text/html; charset=utf-8",
|
|
".msixbundle": "application/msixbundle",
|
|
".msix": "application/msix",
|
|
".deb": "application/vnd.debian.binary-package",
|
|
".gz": "application/gzip",
|
|
".asc": "text/plain",
|
|
"release.gpg": "application/pgp-signature",
|
|
"inrelease": "text/plain",
|
|
"release": "text/plain",
|
|
"packages": "text/plain"
|
|
}
|