docker: adopt the dbuild.sh developer build container - #312
Merged
Conversation
Bring the build-env/dbuild.sh model (validated in the pos_sol, edgem1 and micofe trees) into so3: docker/build-env carries ONLY the environment — both Arm 64-bit toolchains (including the bare-metal aarch64-none-elf the SO3/AVZ kernels need and that hand-provisioned hosts routinely miss), the 32-bit apt toolchains, and the host packages from packages.txt as single source of truth. The repository stays on the host, bind-mounted at its own absolute path so host and container builds share one build/tmp, and the container runs as the calling host user via an entrypoint that maps HOST_UID/HOST_GID and drops privileges with setpriv. scripts/dbuild.sh is the one entry point: --build makes the image, a bare invocation opens an interactive shell with env.sh sourced, and any front-end script runs as-is (dbuild.sh build.sh bsp-linux, dbuild.sh st.sh -d — X11 cookie and display are forwarded). Caller environment variables are not forwarded; pass them through the command (dbuild.sh env IB_FORCE_ATTACH=1 ...). The existing docker/ images are untouched: Dockerfile.toolchains and Dockerfile.env keep serving the CI, the lvperf images the LVGL perf rig. README and the build_system doc point developers at dbuild.sh. Validated: image builds, and front-end scripts run inside the container against this tree (the same files drive the micofe v6.2.4 chain end to end, built and deployed entirely through the container).
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
1 participant
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.
Brings the
build-env/dbuild.shmodel (validated in the pos_sol, edgem1 and micofe trees) into so3.docker/build-envcarries ONLY the environment: both Arm 64-bit toolchains (including the bare-metalaarch64-none-elfthe SO3/AVZ kernels need and that hand-provisioned hosts routinely miss), the 32-bit apt toolchains, and host packages frompackages.txtas the single source of truth. No project source in the image.scripts/dbuild.shis the single entry point:--buildmakes theso3-build:1.0image; a bare invocation opens an interactive shell with env.sh sourced; any front-end script runs as-is (dbuild.sh build.sh bsp-linux,dbuild.sh st.sh -d— X11 forwarded). The repository is bind-mounted at its own absolute path (host and container builds share onebuild/tmp), and the container runs as the calling host user (HOST_UID/GID → setpriv).dbuild.sh env IB_FORCE_ATTACH=1 build.sh ….docker/images are untouched (CIDockerfile.toolchains/Dockerfile.env, lvperf perf-rig images); README andbuild_system.rstnow point developers at dbuild.Validated: image builds (layer-cached against the sibling trees' images), front-end scripts run inside the container against this tree, and the same four files drive the micofe v6.2.4 chain (bsp-linux + bsp-capsules + deploys + QEMU boot) entirely through the container.