fix(ci): give the VS Code dev container its own bazel output base per checkout - #11442
Draft
basvandijk wants to merge 5 commits into
Draft
fix(ci): give the VS Code dev container its own bazel output base per checkout#11442basvandijk wants to merge 5 commits into
basvandijk wants to merge 5 commits into
Conversation
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Checkout paths containing commas break the BAZELRC path and restore the Bazel output-base collision.
Once you've addressed the issues Copilot identified, you can request another Copilot review.
Pull request overview
Adds checkout-specific Bazel output bases for VS Code dev containers to prevent cross-container server conflicts.
Changes:
- Extracts shared Bazel output-base key generation.
- Generates and configures a dev-container-specific bazelrc.
- Documents behavior and worktree limitations.
File summaries
| File | Description |
|---|---|
.devcontainer/devcontainer.json |
Initializes and configures the per-checkout bazelrc. |
ci/container/devcontainer-initialize.sh |
Creates host mounts and the dev-container bazelrc. |
ci/container/bazel-output-base-key.sh |
Generates sanitized checkout keys. |
ci/container/container-run.sh |
Uses the shared key helper. |
ci/container/README.md |
Documents output-base isolation and limitations. |
Review details
- Files reviewed: 5/5 changed files
- Comments generated: 1
- Review effort level: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Base automatically changed from
bas/container-run-per-checkout-output-base
to
master
September 4, 2026 08:59
… checkout
The dev container of .devcontainer/devcontainer.json still used bazel's
default output base, md5("/ic"), so two dev containers opened on two
checkouts (e.g. two git worktrees) killed each other's bazel server the
same way container-run.sh containers did before #11441.
The initializeCommand now runs ci/container/devcontainer-initialize.sh on
the host before the container is created. It creates the bind-mounted
dirs/files as before and writes a bazelrc with
`startup --output_base=~/.cache/bazel/_bazel_ubuntu/devcontainer-<key>`
under ~/.cache/container-run/devcontainer<checkout path>/, which
containerEnv's BAZELRC points at through the ~/.cache mount. The key
computation is shared with container-run.sh via the new
ci/container/bazel-output-base-key.sh (keys are unchanged). The
"devcontainer-" prefix keeps the dev container's output base distinct from
the container-run.sh one of the same checkout: they run in separate PID
namespaces, so the Bazel extension's background queries would otherwise
kill a server running in the other container.
Existing dev containers need one "Rebuild Container" for the new
containerEnv to take effect and then start with a cold output base. Git in
a dev container opened on a linked worktree remains unsupported (VS Code's
experimental worktree mount is skipped when workspaceMount is customized,
microsoft/vscode-remote-release#11478); this is documented in the README.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…he checkout path
$BAZELRC is a comma-separated list, so a checkout path containing a comma
would be split into two rc paths and bazel would silently fall back to the
shared default output base. Key the generated rc file on ${devcontainerId}
instead, a stable per-checkout base32 hash that the Dev Container tooling
substitutes in both containerEnv and initializeCommand, so no host path
appears in BAZELRC. The output base name itself is unchanged.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
basvandijk
force-pushed
the
bas/devcontainer-per-checkout-output-base
branch
from
September 4, 2026 08:59
b013de5 to
b10bbab
Compare
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.
What
#11441 supported invoking bazel concurrently from different containers run by
container-run.sh. This uses the same approach for containers run by.devcontainer/devcontainer.json.How
The dev container of
.devcontainer/devcontainer.jsonstill used bazel'sdefault output base,
md5("/ic"), so two dev containers opened on twocheckouts (e.g. two git worktrees) killed each other's bazel server the
same way
container-run.shcontainers did before #11441.The
initializeCommandnow runsci/container/devcontainer-initialize.shonthe host before the container is created. It creates the bind-mounted
dirs/files as before and writes a bazelrc with
startup --output_base=~/.cache/bazel/_bazel_ubuntu/devcontainer-<key>to
~/.cache/container-run/devcontainer-<devcontainerId>.bazelrc(a stableper-checkout hash substituted by the Dev Container tooling; BAZELRC is
comma-separated, so the checkout path must not appear in it), which
containerEnv's BAZELRC points at through the
~/.cachemount. The keycomputation is shared with
container-run.shvia the newci/container/bazel-output-base-key.sh(keys are unchanged). The"devcontainer-" prefix keeps the dev container's output base distinct from
the container-run.sh one of the same checkout: they run in separate PID
namespaces, so the Bazel extension's background queries would otherwise
kill a server running in the other container.
Existing dev containers need one "Rebuild Container" for the new
containerEnv to take effect and then start with a cold output base. Git in
a dev container opened on a linked worktree remains unsupported (VS Code's
experimental worktree mount is skipped when workspaceMount is customized,
microsoft/vscode-remote-release#11478); this is documented in the README.