build: regenerate checksums when promoting LTS/RC releases (#36237)
The LTS/RC promotion workflow re-stamps the already published stable or
canary binaries: it runs patchver to write the channel marker and then
re-signs the result. That changes the binary bytes, and therefore the
zip bytes, but the upload step only pushes the new deno-*.zip and
denort-*.zip archives to dl.deno.land. The *.sha256sum sidecars from the
source release are left in the bucket untouched, so after promotion they
describe the old artifacts and no longer match what is served.
This is what #36235 reports for v2.9.3: dl.deno.land serves a
deno-x86_64-unknown-linux-gnu.zip that hashes to c4b10eda..., while the
co-located .zip.sha256sum still carries the stable release value
8101865.... The bare-binary .sha256sum is stale for the same reason.
Anyone verifying a download from dl.deno.land against its sidecar fails.
The fix regenerates both the .zip.sha256sum and the bare-binary
.sha256sum from the promoted archives right before upload, and uploads
them alongside the zips. Regenerating from the actual promoted v2.9.3
LTS zip reproduces the correct values (c4b10eda... for the zip, 6ec58230...
for the binary), confirming the logic.
Note this only fixes future promotions. The already published v2.9.3 LTS
sidecars on dl.deno.land still need to be regenerated and re-uploaded
out of band, since they were produced before this change.
deno
79d46527 - build: regenerate checksums when promoting LTS/RC releases (#36237)
