fix(deploy): download release artifacts one at a time, by name - #48
Merged
Conversation
The GitHub release job failed on v0.1.0-rc.1 and failed again identically on a re-run: Unable to download artifact(s): Unable to download and extract artifact: Artifact download failed after 5 retries. Not flakiness. A single unfiltered download with merge-multiple fetched five artifacts totalling ~168 MB concurrently and extracted them all into one shared directory; the log shows some completing before the batch gave up. Now each is named and lands in its own directory, so nothing is concurrent and nothing is shared. Naming them also fixes a bug nobody had hit yet: buildx uploads a *.dockerbuild build trace, and the unfiltered download swept it in. It would have been published as a release asset and listed in SHA256SUMS beside the binaries, as though it were something to install. A guard now fails the job if anything other than rsagent-worker-* is staged, rather than publishing it. SHA256SUMS is generated from the rsagent-worker-* prefix rather than *, so it cannot list itself whichever order the shell performs expansion and redirection in. npm and both container registries published correctly on rc.1, so this was the only part of the pipeline still unproven — the release job is skipped on a dry run, because it is gated on a tag. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01AyYg2j8FVkLjiaVcj5HCkj
semics-tech
added a commit
that referenced
this pull request
Jul 30, 2026
Promotes the release candidate. rc.1 published correctly to npm and both container registries — **trusted publishing works**. The two bugs it surfaced (concurrent artifact download, and buildx's `.dockerbuild` trace being swept into the release assets) are fixed in #48. `prerelease=false`, so this moves npm's `latest` off the `0.0.0` bootstrap placeholder and gives Docker Hub its `latest` and `0.1` tags — the thing that makes plain `npm install` and `docker pull` work. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01AyYg2j8FVkLjiaVcj5HCkj Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The GitHub release job failed on
v0.1.0-rc.1, and failed again identically on a re-run:Not flakiness. A single unfiltered
download-artifactwithmerge-multiple: truefetched five artifacts totalling ~168 MB concurrently, extracting them all into one shared directory. The log shows some completing before the batch gave up. Each is now named and lands in its own directory — nothing concurrent, nothing shared.A second bug it was hiding
Naming the artifacts also keeps out buildx's
*.dockerbuildbuild trace, which the unfiltered download swept in. It would have been published as a release asset and listed inSHA256SUMSbeside the binaries, as though it were something to install.A guard now fails the job if anything other than
rsagent-worker-*is staged, rather than publishing it. Verified it trips on a planted.dockerbuildfile.SHA256SUMSis also now generated from thersagent-worker-*prefix rather than*, so it can't list itself depending on when the shell creates the redirect target.Context
npm and both container registries published correctly on rc.1 — trusted publishing works. This job was the only part of the pipeline still unproven, because it's gated on
github.ref_type == 'tag'and so is skipped on every dry run.🤖 Generated with Claude Code
https://claude.ai/code/session_01AyYg2j8FVkLjiaVcj5HCkj