Repository navigation
fix(genvm): download GenVM releases instead of building from source - #1706
Conversation
Studio always built GenVM from source because the pin file held a floating "main". That nix build fails nondeterministically on a fixed-output derivation, so add explicit prebuilt/source/release modes and default to downloading a pinned genvm-manager release.
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The genvm-manager bundle carries two executor lines, so precompiling both on a cold cache overruns the healthcheck window and the container is reported unhealthy. Precompile in a one-off container first and cache the result across runs.
|
…1706) (#1712) * fix(genvm): acquire GenVM by release download instead of nix build Studio always built GenVM from source because the pin file held a floating "main". That nix build fails nondeterministically on a fixed-output derivation, so add explicit prebuilt/source/release modes and default to downloading a pinned genvm-manager release. * fix(ci): precompile GenVM before starting the stack The genvm-manager bundle carries two executor lines, so precompiling both on a cold cache overruns the healthcheck window and the container is reported unhealthy. Precompile in a one-off container first and cache the result across runs.
1 participant
Follow-up to #1697. Targets that PR's branch, so #1697 still merges to
v0.123-devas one unit.Problem
third_party/genvm/versionheld the literal stringmain, and the pin router sends anything not matching^v[0-9]down the nix path. So every build compiled GenVM from source against a floating ref — the input silently moved (it resolved to02741163at CI time, now12f85fc0).That nix build fails nondeterministically: FOD mismatch on
genvm-bz2-1.0.8wherespecified:is constant butgot:differs across jobs (sandbox is disabled, so host state leaks in). Bumping the hash does not fix it.02741163is exactly thev0.6.0-rc0tag, and that release ships a self-contained prebuilt bundle. We were compiling something that already exists as a download.Change
Three explicit acquisition modes, precedence prebuilt > source > release:
prebuilt.e2e-genvm-prebuilt/tree presentsourceGENVM_SOURCE_MODE=source, or<branch>:<commit>inGENVM_REFreleasegenvm-managerreleasemain→v0.6.0-rc0download_genvm.shrather than writing a third implementation — keeps the tree-based split-layout probe (rc1 movedrunners/into a separategenvm-universal.tar.xz; the probe checks the tree, never the tag),chmod -R u+wfor rc0's read-onlydata/, thepost-install.py/genvm-post-installrename handling, and the pinned-runner assertiongenvm-runner-pinstage collapses contract pins to a small normalized file, so the ~330MB GenVM layer no longer invalidates on every backend editGENVM_TAG/GENVM_REFmutual-exclusion guardGENVM_ARTIFACT_URL— it was half-wired (hardcoded amd64-only default, absent from compose, unreachable-zguard). It silently fetched an amd64 bundle on arm64.-devbranch pins now rejected with an actionable message instead of 404ing.dockerignore:!docker/scripts/is load-bearing — without it the newCOPYfails and every build breaks in all three modesGENVM_TAG's ENV is deliberately kept: it is dead at build time but load-bearing at runtime as the precompile cache-key fallback.Verification
Built locally on arm64. Release mode green; image carries
/genvm/version=v0.6.0-rc0, executorsv0.2.17+v0.3.0-rc7, and the pinned runner9b/8kjyda2…tar— the tarball whose absence caused the original lint failure. Arch resolved to arm64 correctly.Negative cases all behave:
prebuilt+ unusable treeGENVM_TAG+GENVM_REFboth setGENVM_TAG=v0.6-dev(a branch)Source mode is untested here — it is the known-broken nix path, now opt-in precisely so nobody hits it by accident.
Not addressed
Lint Intelligent Contractsfailure is a separate problem:genvm-linterresolves its bundle from the oldgenlayerlabs/genvmrepo (stops atv0.3.0-rc7), which does not contain the9b8kjyda2…hash. Needs the linter pointed at a bundle that has it.genvm-lint.ymldeliberately untouched.keccak.py, 439 untested lines).Depends-On: genlayerlabs/genlayer-e2e@fix/studio-genvm-source-mode