Repository navigation
feat(sandbox): test a Microsandbox pin before the fork releases its runtime - #327
Merged
Merged
Conversation
…untime A Sandbox Provider installs the runtime from AGENT_MICROSANDBOX_RUNTIME_DIR when it is set, still checked against the pinned digest. sandbox/microsandbox/fetch-runtime.sh fills that directory from the fork's release-<tree> artifact, the files its release later publishes, and the end-to-end job does so while the pinned version has no release. Part of #279.
Contributor
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the
|
martinothamar
force-pushed
the
feat/microsandbox-runtime-dir
branch
from
October 25, 2026 14:57
d2aaa18 to
13951f7
Compare
martinothamar
marked this pull request as ready for review
October 25, 2026 15:18
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.
Outcome
A Microsandbox pin update can run its end-to-end tests, locally and in this repository's CI, while the fork's synchronization is still in review. Until now those tests could only start after the fork had published its release, because the runtime was installed from the release download. A fix the pin update turns out to need then went into another fork release, as happened with
0.7.8-digdir.2. Now it can go into the synchronization before it lands.This is the mechanism decided in #279. It builds on digdir/microsandbox#5: every successful check run in the fork assembles the release files of the tree it built, keeps them as the
release-<tree>artifact, and the fork's release later publishes exactly those files. So the bundle digests a pin update copies intoclient.rsare final before the release exists.What changes
AGENT_MICROSANDBOX_RUNTIME_DIR. When it names a directory, a Sandbox Provider installs the runtime from the platform's bundle in that directory instead of downloading the release. The bundle must still match the digest pinned inclient.rs, so this only changes where the same bytes come from. A missing bundle is an error, not a fallback to the download. When the variable is unset, which it is in every release and normal use, nothing changes.sandbox/microsandbox/fetch-runtime.sh <directory> [commit]. It takes the Microsandbox commit pinned inCargo.lock(or the given commit), finds the oldest successfulcheck-digdir.ymlrun in digdir/microsandbox that built that commit's tree, the same run the fork's release takes its files from, and downloads that run'srelease-<tree>artifact. Then it verifies the files against theirchecksums.sha256and prints each bundle's digest and whetherclient.rspins it. It needsghwith read access.v<version>exists in digdir/microsandbox. The fork creates the tag when it publishes the release. If the tag is missing, the job runs the script and sets the variable beforemake test-e2e. For the current pin,0.7.8-digdir.2, the tag exists, so the job behaves as before.sandbox/docs/microsandbox-upgrade.mdgets a "Before the release" section with the steps for a pin update.Steps for the next pin update
sync/digdir-X.Y.Z. When the synchronization lands,main-digdirmoves to that same commit, so the pin stays valid.sandbox/microsandbox/fetch-runtime.sh <directory>and copy the printed digests intoclient.rs.AGENT_MICROSANDBOX_RUNTIME_DIR=<directory>and runmake check. In the pull request, CI does this itself.Evidence
Locally, with the artifact of
main-digdir's tip29be50d7, which has the same version as the current pin:release-7199709b…, downloaded and verified it, and printed the 5 bundle digests as not pinned.runtime::retained_lifecycle_execution_files_and_volumeswith the variable set:AGENT_MICROSANDBOX_RUNTIME_DIR has no Microsandbox runtime bundle …/microsandbox-linux-x86_64.tar.gz;runtime archive SHA-256 mismatch: expected fde2297f…, got 59f570ba…;59f570ba…, it installs the runtime from the directory and passes.make fmt lint build test, shellcheck and actionlint pass.In CI, see No secret needed.
No secret needed
A workflow's own token can download digdir/microsandbox's artifacts, since that repository is public. A temporary commit, since dropped, ran the script in this pull request's end-to-end job against
29be50d7: it found, downloaded and verified the artifact in 9 seconds withgithub.token.Costs
The artifact is about 500 MB, of which 240 MB is the kernel source the fork publishes for the GPL. The script downloads it whole, because an artifact can only be downloaded as one zip. On a GitHub-hosted runner that takes about 9 seconds, and 3.5 minutes on this Agent's connection. Only pin updates whose version has no release yet pay it.
Part of #279.