Repository navigation
refactor(os-image): e2b-ci fetches e2b's recipe at a pinned sha instead of vendoring it - #253
Merged
Merged
Conversation
…ad of vendoring it The build stage downloads e2b-dev/code-interpreter at CI_RECIPE_SHA, checks the archive's sha256, takes template/ and LICENSE, and applies javascript-context.patch, our permanent guard for the python-only flavor. The e2b_charts pin lives in constraints.txt, so upstream's requirements.txt is used as is, and e2b's license ships in the image. A recipe upgrade is one sha bump plus a constraints refresh.
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.
E1b:
e2b-cistops vendoring e2b's recipe. The owner rejected the copy in #251, because 2620 of its lines were e2b's own source.Change
e2b-dev/code-interpreteratCI_RECIPE_SHA(f56a1edf75) and checks the archive againstCI_RECIPE_SHA256. It keeps onlytemplate/andLICENSE, then runspatch -p1withjavascript-context.patch.PATCHESdescribes it, and every recipe bump re-applies it.requirements.txtused as is: thee2b_chartspin already lives inconstraints.txt./usr/share/doc/e2b-code-interpreter/LICENSE.os-image/e2b-ci/code-interpreter/. What remains is the Dockerfile with the sha as an ARG, the two constraints files, the two units,platforms, the patch plusPATCHES, and the docs.CI_RECIPE_*args and refresh the constraints.dockerexporter ignoresrewrite-timestamp, so a local check exports OCI.Evidence
--no-cacheOCI builds of this tree (linux/amd64, pinned base digest,SOURCE_DATE_EPOCH,rewrite-timestamp=true) gave the same manifestsha256:cc47851d6a80c0a97afbb26cddd84e6a3b82cadc7813a5354c0dd325679e02eaand the same single layersha256:58050a7dfeff8eef6db08bdba5fd79f87940a3af505353feb31e4c5c5962f390.recipe.tar.gz: OKandpatching file template/server/main.py. The layer containsusr/share/doc/e2b-code-interpreter/LICENSE, androot/.server/main.pyhas the kernelspec guard.envd-e2e.shwithSIZE=medium CODE_INTERPRETER=1, on host A's isolated root: every step ok,interpreter runs 1+1in 75.3ms,ENVDSMOKE PASS.e2b-code-interpreter2.10.0:run_code('1+1')returned'2', 164 ms from create.@e2b/code-interpreter2.8.0:runCode('1+1')returned"2", 189 ms from create.envdsmokeandenvd-e2e.sh.LOC
+58 / −2638, net −2580. No Go changes.