Repository navigation
Publish release binaries without archives - #666
Conversation
Replace release archives with lowercase platform-qualified executables. Acquire matching counterparts from GitHub asset URLs and SHA-256 digests, reusing plugin metadata when supplied. Amp-Thread-ID: T-78391034-3dd4-4b62-add4-43b0c384ed45
There was a problem hiding this comment.
The raw-only format intentionally stops archive-only installers from following new tags, so human approval is required for the release-asset compatibility break. One non-blocking shared-IP rate-limit concern is inline.
Want to dig deeper?
Paste this into your agent to explore the findings from this review's Buildkite build:
Download the buildsworth logs from build 51298, then answer my questions about the findings.
Install the reading-buildsworth-logs skill to run this.
About buildsworth
Model: gpt-6.1-sol with xhigh thinking.
How to request a review: Comment @buildsworth-bk review on the PR, or request buildsworth-bk as a reviewer.
Risk labels (how buildsworth classifies risk) — buildsworth classifies risk itself from the diff. The same approval policy applies in every repository:
- L1 — Low risk (dep bumps, docs/copy, lockfiles, small presentational fixes). buildsworth may approve by default.
- L2 — Standard risk (new UI, additive API fields, refactors). buildsworth may approve without per-PR permission.
- L3 — High risk (auth, migrations, payments, secrets, perf-critical pipeline paths). Human approval required; buildsworth never approves.
| data := []byte(metadata) | ||
| if !provided { | ||
| var err error | ||
| data, err = downloadPluginReleaseFile(ctx, pluginHTTPClient, pluginReleaseAPIURL+url.PathEscape("v"+version), version, pluginReleaseMetadataLimit) |
There was a problem hiding this comment.
Non-blocking: The released v0.14.0 plugin never supplies this handoff, so every import needing a counterpart makes an anonymous GitHub REST request here, even with a warm binary cache. On self-hosted agents sharing an egress IP, roughly 60 such imports/hour exhaust the anonymous quota and subsequent imports fail before pipeline upload; the old static checksum download did not consume that quota. Reusing trusted release metadata or an authenticated metadata path would avoid this regression.
Amp-Thread-ID: https://ampcode.com/threads/T-c9a8c87e-cf09-468c-9709-79fb84c4a1be Co-authored-by: Amp <amp@ampcode.com>
Compare all four executable checksums across repeated snapshot builds and document the inputs needed to reproduce published binaries. Co-authored-by: Amp <amp@ampcode.com> Amp-Thread-ID: https://ampcode.com/threads/T-c9a8c87e-cf09-468c-9709-79fb84c4a1be
|
🤖 Released in v0.129.0 |
🤖
Why
Release digests currently identify archives, not executables. Comparing an importer with its published binary therefore requires downloading and extracting its archive first.
What
Publish raw binaries for all four targets, retaining
checksums.txt:Lowercase OS names let released mise-based plugins install the executable under the correct command name. Ship the matching CLI downloader in the same release: it selects counterparts from the running version and verifies GitHub API asset digests, without fetching
checksums.txt. It can reuse plugin-provided release metadata or fetch exact-tag metadata once. Cached bytes remain digest-verified; custom and local binaries keep their existing behavior.Historical releases remain unchanged. Old archive-only installers can retain historical pins but cannot select new raw-only tags. Missing assets or digests fail closed; there is no archive fallback. This prerequisite does not yet remove per-build runtime artifacts or replace the plugin bootstrap.