Run the Docker image smoke test on release branches, not only main - #2565
Merged
Conversation
The publish workflow builds the image from a release branch, and this smoke test is the only thing that boots the built image — but its push trigger was `branches: [main]`, so no release branch has ever run it. A v5.x branch could carry an image that fails at startup and nothing in its own CI would say so. Found while verifying v5.2 for a 5.2 patch: the shrinkwrap single-instance guard was cherry-picked onto v5.2 specifically so the release branch would prove root and rocksdb-js share one msgpackr instance, and the check it runs under could not fire there. That property had to be verified by hand instead. Uses the same branch pattern as unit-test.yml, which already covers both. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
github-actions
Bot
requested review from
Ethan-Arrowood,
cb1kenobi and
heskew
September 10, 2026 15:50
Contributor
|
Reviewed; no blockers found. |
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.
docker-smoke.yml's push trigger wasbranches: [main], so no release branch has ever run it. That matters because the publish workflow builds the image from a release branch, and this smoke test is the only thing in CI that boots the built image — av5.xbranch could carry an image that fails at startup and nothing in its own CI would say so.Found while verifying
v5.2for the 5.2 patch. #2560's shrinkwrap single-instance guard was cherry-picked ontov5.2precisely so the release branch would prove that root and@harperfast/rocksdb-jsshare onemsgpackrinstance — and the only check that runs that guard could not fire there. The property had to be verified by hand instead:resolved from both the root and from rocksdb-js's own resolution path, plus the checker's own suite 20/20 on
v5.2. That is the evidence the smoke test would have produced automatically.Uses the same branch pattern as
unit-test.yml([main, 'v[0-9]+.[0-9]+']), which already covers both. Thepaths:filter is unchanged, so this only fires on release-branch pushes that actually touch the image inputs.Verification
The workflow parses and the trigger resolves as intended:
Trigger-only change; there is no behaviour to unit test. The job itself is unchanged and is exercised by this PR's own
pull_requestrun.Note for whoever merges
Milestone deliberately left unset. Setting it to
v5.2would cherry-pick this onto the release branch and givev5.2real image coverage — but it introduces a new check on a branch that is otherwise green and ready to tag, so that is a release-timing call rather than a code one.🤖 Generated with Claude Code