Repository navigation
ci(docker): only upload standalone binaries when a release will use them - #223
Merged
Merged
Conversation
Since #112 the build job exports and packages the standalone binaries on every run, then uploads them as an artifact. Only the release job consumes that artifact, and it runs on a version tag or a dry-run dispatch, so every PR and branch push currently stores an archive nobody downloads. Gate just the upload. Export and packaging stay ungated on purpose: they are what proves the `standalone` stage still builds, and moving that check to release time is exactly the trap of a gate that cannot fail until it matters. The condition deliberately mirrors the release job's, including the workflow_dispatch dry run. A bare `startsWith(github.ref, 'refs/tags/v')` would make the dry-run rehearsal fail at download-artifact, which is the one path that exists to prove the release sequence works without cutting a tag.
Contributor
There was a problem hiding this comment.
✅ No new issues found.
Reviewed changes
- Gate the standalone artifact upload — adds an
if:to thebuildjob'sUpload standalone binariesstep sostandalone-binariesis only uploaded when thereleasejob will download it; export and packaging stay ungated so thestandalonestage is still exercised on every PR and branch push. - Condition matches the release job exactly — the new step condition is identical to the
releasejob'sif:(.github/workflows/docker-publish.yml:291), preserving theworkflow_dispatchdry-run rehearsal path that downloads the artifact. - Documented rationale — the added comment explains why export/packaging must not be gated and why the condition must stay in sync with
release.
The PR's own pull_request run confirms the intended behavior: Export standalone binaries and Package standalone binaries succeeded while Upload standalone binaries was skipped. Only the release job consumes the artifact, so no other consumer is left without it.
deepseek-v4.1-flash | 𝕏
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
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.

Follow-up to #112, which was merged before this could be added.
Problem
Since #112 the
buildjob exports and packages the standalone binaries on every run, then uploads them as an artifact. Only thereleasejob downloads that artifact, and it runs on a version tag or a dry-run dispatch. So every PR and every branch push stores an archive nobody consumes.Change
Gate the upload step only:
Export and packaging stay ungated on purpose. They are what proves the
standalonestage still builds. Gating them would move that check to release time, which is the trap of a gate nobody exercises until it matters.The condition is not a bare tag check
The obvious
startsWith(github.ref, 'refs/tags/v')would break thedry_runrehearsal, because the release job also runs on a dry-run dispatch and its first step isdownload-artifact. A bare tag check would leave it with nothing to download, killing the one path that exists to prove the release sequence works without cutting a tag. The gate therefore mirrors the release job's condition exactly, which is verified below.Verification
Parsed from the workflow:
On this PR the upload should be skipped while export and packaging still run. After merging I will dispatch
dry_run=trueagainstmainto prove the opposite case: upload runs, the release job downloads the artifact and rehearses, and it stops before creating a Release.