fix(bundle): Pin urunc and urunit to a commit - #10
Merged
Merged
Conversation
ananos
force-pushed
the
fix/pin-urunc-urunit-commits
branch
from
September 25, 2026 22:44
3761410 to
35d12f3
Compare
build-bundle.sh named urunc and urunit by branch only. It cloned the tip of feat/unchanged_containers and of urunit_agent, and recorded whatever commit that was in pins.env after the fact. A push to either branch changed the next bundle with no change here. Two builds of one bundle version could carry different code, and no review ever saw the move. Each is now pinned to one commit, URUNC_REF_DEFAULT and URUNIT_REF_DEFAULT. The build fetches that commit by its SHA, since a --depth 1 --branch clone stops containing a pinned commit as soon as the branch moves on. It then fails if HEAD is anything else. pins.env records the commits in URUNC_REF and URUNIT_REF as before, and adds URUNC_PINNED and URUNIT_PINNED. The urunc pin moves to 0818ff1 on feat/unchanged_containers-exec-fixes. That is feat/unchanged_containers (b2c3cb1, which rc6 to rc8 built) plus the two urunit-agent exec fixes: urunc-dev/urunc#1059, which relays a guest exec's output before reporting its exit, and urunc-dev/urunc#1060, which accepts agent connections with close-on-exec. The agent in the initrd is built from the same checkout. The urunit pin is 71bfdee, the tip of urunit_agent and what rc6 to rc8 shipped. URUNC_REF and URUNIT_REF use ${VAR-default}. Unset takes the pin, a SHA builds that commit, and an empty value builds the tip of *_BRANCH, with a warning in the build log and *_PINNED=false in pins.env. A branch set without a ref is refused, and so is a ref that is not a full SHA. The stock variant keeps its paths: with --urunc-version it takes the release, and it builds no urunit. README.md, DESIGN.md and docs/variants.md name the pinned commits and say how to move a pin. tests/source-pins.sh runs build-bundle.sh against a stub git and docker, so nothing is fetched. It checks that a default build fetches both pins by SHA, that a checkout other than the pin fails the build, that an empty ref builds the branch tip and warns, and that a branch without a ref or a short ref is refused. Against the previous build-bundle.sh, with the pins filled in by hand, it fails the first check: the build asks for `git clone --depth 1 --branch feat/unchanged_containers`. CI runs it in a new Script tests step. CI's bundle job now also checks that each built pins.env carries the pinned commits and *_PINNED=true. Signed-off-by: Anastassios Nanos <ananos@nofire.ai>
ananos
force-pushed
the
fix/pin-urunc-urunit-commits
branch
from
September 25, 2026 22:52
35d12f3 to
2cab889
Compare
ananos
marked this pull request as ready for review
September 25, 2026 22:56
5 tasks
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.
Summary
build-bundle.shnamed urunc and urunit by branch only (URUNC_BRANCHfeat/unchanged_containers,URUNIT_BRANCHurunit_agent). It cloned thebranch tip, built it, and recorded the resulting commit in
pins.envafter thefact. A push to either branch changed the next bundle with no change in this
repository. Two builds of one bundle version could carry different code, and no
review ever saw the move.
A branch tip is not a release input. This pins each of the two to one commit,
fetches that commit by its SHA, and fails the build if the checkout is anything
else.
The urunc pin also moves, to
feat/unchanged_containers-exec-fixesat0818ff104781087a12a75059062c3407a8b97c8a. That isfeat/unchanged_containers(
b2c3cb1, which rc6 to rc8 built) plus the twourunit-agentexec fixes:The exec agent (
/urunit-agent) in the initrd is built from the same urunccheckout, so it carries both. The urunit pin is
71bfdeefb7bced121c4e75afa97550523af34152, the tip ofurunit_agentand whatrc6 to rc8 shipped.
Once this and #6, #7, #8 and #9 are merged, bundle rc9 should be cut from
main. brig'sinstall.shthen moves its runtime pin fromv0.1.0-rc8to rc9,in a separate brig PR.
Changes
URUNC_REF_DEFAULTandURUNIT_REF_DEFAULTinbuild-bundle.shhold thereviewed pins. Moving one is a one-line change, plus its
*_BRANCH_DEFAULTwhen the commit comes from another branch.
git init,git fetch --depth 1 origin <sha>, and a checkoutof
FETCH_HEAD. A--depth 1 --branchclone stops containing a pinnedcommit as soon as the branch moves on, and GitHub serves any reachable commit
by SHA, a pull request's head included. The build fails if
HEADis not thepin.
URUNC_REFandURUNIT_REFuse${VAR-default}, so each has three states:URUNC_REF=): the tip of*_BRANCH, on purpose. The build logwarns, and
pins.envgetsURUNC_PINNED=falseand a warning comment.*_BRANCHset without its*_REFis refused: it is unclear whether thebranch or the pin was meant. A ref that is not a full SHA is refused too, since
it could never match
HEAD.pins.envkeepsURUNC_REFandURUNIT_REF(andURUNC_BRANCH,URUNIT_BRANCH,INITRD_SOURCE,ASSETS_URUNC_REF,bundle.json) exactly asbefore, and adds
URUNC_PINNEDandURUNIT_PINNED.stockvariant keeps its paths: with--urunc-versionit takes therelease and records
URUNC_PINNED=true, and it builds no urunit.mainhas nolocal-source override, so there is none to keep.
DESIGN.mdanddocs/variants.mdname the commits and say how and why a pin moves.tests/source-pins.shin aScript testsstep (the same step as fix(rootless): Give each user a device grant of their own #6, fix(bundle): Run brig-ctl's ctr inside the rootless namespace #8and fix(install): Name the bundle in the install summary #9, word for word), and the bundle job checks that every built
pins.envcarries the script's pins with
*_PINNED=true.This branch is independent of #6 to #9. It applies cleanly beside each of them,
in either order, and beside all four together. The five tests pass on the
combination.
Testing
tests/source-pins.shrunsbuild-bundle.shagainst a stubgitanddocker,so nothing is fetched:
Against
main'sbuild-bundle.sh, it fails at once (no URUNC_REF_DEFAULT in build-bundle.sh). With the pins filled into the test by hand, it fails the firstcheck, and shows what
mainasks git for:The script's own
checkout_source, run for real against GitHub:The CI
pins.envcheck, run against the v0.1.0-rc8 record (whatmainbuildstoday) and against one that carries the pins:
sh -n(dash) andshellcheck -s shpass overinstall.sh,build-bundle.sh, the three generated scripts and the test.The four CI bundle builds
All four passed on this PR (run 36197316349).
Each log checked out the pinned urunc and urunit, and the new check read the
built
pins.env:The amd64 plain artifact, downloaded and unpacked. Its
bundle.jsonnames bothcommits, and the agent in its
container-initrdwas built from0818ff1:INITRD_SOURCEandASSETS_URUNC_REFin thatpins.envboth readbuilt:0818ff1...and0818ff1...in full, as before.🤖 Generated with Claude Code