ci: run workflows on the release branch and restore reproducible image builds - #1028
Open
kvinwang wants to merge 3 commits into
Open
ci: run workflows on the release branch and restore reproducible image builds#1028kvinwang wants to merge 3 commits into
kvinwang wants to merge 3 commits into
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates CI workflow branch filters on the release/v0.5.x line so that GitHub Actions runs on release branches (which currently receive no CI due to legacy filters targeting master, next, and dev-*).
Changes:
- Updated
pushandpull_requestbranch filters in six workflows to run only onrelease/**. - Removed stale branch filter references (
master,next,dev-*, andmaininspdx-check.yml) from workflow triggers.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| .github/workflows/vmm-ui.yml | Switches CI triggers to release/** so VMM UI build runs on release branches. |
| .github/workflows/spdx-check.yml | Switches reuse-lint triggers to release/** so SPDX/REUSE checks run on release branches. |
| .github/workflows/sdk.yaml | Switches SDK tests triggers to release/** so SDK CI runs on release branches. |
| .github/workflows/rust.yml | Switches Rust checks triggers to release/** so core Rust CI runs on release branches. |
| .github/workflows/prek-check.yml | Switches Prek checks triggers to release/** so Prek CI runs on release branches. |
| .github/workflows/docker-build-check.yml | Switches Docker build check triggers to release/** so container build validation runs on release branches. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
kvinwang
force-pushed
the
ci/enable-release-branch-checks
branch
from
August 7, 2026 15:15
6b339dc to
8737b47
Compare
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.
Problem
Two separate defects on
release/v0.5.x, one of which hides the other.1. The branch has no CI at all
release/v0.5.xwas cut fromv0.5.11and carries that eras workflow files, whose branch filters are[ master, next, dev-* ](and[ master, main ]forspdx-check.yml). None matchrelease/v0.5.x, so creating the branch triggered zero workflow runs.This cannot be fixed from
next. For bothpushandpull_request, GitHub runs the workflow files as they exist on the branch being built, so addingrelease/**to the filters onnext(already done) only helps release branches cut fromnextlater. The fix has to land here.masterno longer exists at all, so these filters currently name two branches that cannot match and one that is gone.2. The gateway and KMS builder images are not reproducible
Once CI does run,
docker-build-checkfails onVerify builder pinned packagesfor bothgatewayandkms:This is not benign upstream churn — it means rebuilding the same commit today produces a different image than the pinned list records, which defeats the point of pinning on a project whose security argument rests on measured, verifiable images.
The cause is
build/shared/pin-packages.sh. It hardcodesbookwormand only overwrites/etc/apt/sources.list.gateway/dstack-app/builderandkms/dstack-app/builderboth buildFROM rust:1.92.0, which is trixie, and trixie ships its sources via deb822 at/etc/apt/sources.list.d/debian.sources. That file is left untouched, so apt keeps resolving from livedeb.debian.organd the snapshot pin is bypassed entirely.verifier/builderusesrust:1.92.0-bookwormexplicitly, which is why it is unaffected and passes.Fix
Three commits:
ci: run workflows on the release branch— point the six filtered workflows atrelease/**(a glob rather than a literal, so the file stays correct if this line is ever branched further).style: fix trailing whitespace in spdx-check workflow— trailing whitespace and a missing EOF newline that have been in that file since v0.5.11. prek only inspects changed files, so touching the file surfaced them.fix(ci): lock snapshot for Debian 13 (trixie) base images— backport of6a345f75e(chore(ci): bump builder pinned packages for Debian upstream drift #688) plus its follow-up6a87118b9fromnext, squashed into one commit since they are two halves of the same fix (the follow-up adds the# shellcheck source=/dev/nulldirective that SC1091 requires for the. /etc/os-release). DetectsVERSION_CODENAMEfrom/etc/os-release, wipes both the legacy and deb822 source layouts, and rewritessources.listagainst the snapshot for the detected suite.Confirmed: no pinned-package list needed regenerating.
gatewayandkmsboth went green on this branch with the lists untouched, which is the proof the section below predicted.No pinned-package list is regenerated, deliberately. The lists on this branch still hold the original snapshot-correct values (
openssl=3.5.5-1~deb13u1,musl:amd64=1.2.5-3,protobuf-compiler=3.21.12-11) — nobody ever bumped them here to paper over the drift, unlike onnextwhere6a345f75ehad to revert exactly such a bump. With the snapshot pin working again, apt should resolve back to the versions already recorded. This was the falsifiable prediction, and it held:gateway8m27s andkms12m3s both pass with the lists unchanged.verifier(11m18s) also passes, as expected — it buildsFROM rust:1.92.0-bookwormand was never affected.The script hunk was applied from
6a345f75eunchanged — this branchs copy ofpin-packages.shis byte-identical to the pre-fix version, so there was nothing to adapt.Verification
push/pull_requeston[release/**]uniformly. Nomaster/next/dev-*branch filter remains under.github/workflows/.bash -n build/shared/pin-packages.shpasses, and the resulting file is byte-identical tonext'sdstack/build/shared/pin-packages.sh.gatewayandkmsmoved fail -> pass on the pinned-package verification step with no change to the pinned lists themselves.rust-checks(9m14s),sdk-tests(7m20s),reuse-lint(12s),prek(29s) and the mkosibuildjob all pass. Onlygatewayandkmsfailed, and only on the pinned-package step.gateway-release.yml,kms-release.yml,rust-sdk-release.yml,simulator-release.yml,verifier-release.yml) carry no branch filter and are untouched.Follow-up
Once green,
release/**can take arequired_status_checksruleset withrust-checks,sdk-tests,reuse-lint,prek. That is deliberately not part of this PR — adding the rule before CI dispatches on the branch would leave every backport PR pending forever, the same trap #1025 had to pre-empt for the branch rename.release/v0.3.xmust be excluded from that ruleset regardless: it carries onlyrust.yml, so the other three contexts can never report there.