Skip to content

test(ci): add ci/container/test-container-run.sh and run it per container runtime - #11461

Draft
basvandijk wants to merge 5 commits into
masterfrom
bas/test-container-run
Draft

test(ci): add ci/container/test-container-run.sh and run it per container runtime#11461
basvandijk wants to merge 5 commits into
masterfrom
bas/test-container-run

Conversation

@basvandijk

@basvandijk basvandijk commented Sep 5, 2026

Copy link
Copy Markdown
Collaborator

Stacked on #11460 (mount the checkout at its host path); review that one first.

Change

  • fix(ci): --user "$CTR_USER" instead of --user "$CTR_USER:$CTR_USER". /home/ubuntu is mode 750 in the base image and buildifier is in group ubuntu so that it can read the /home/ubuntu/.ic-build-container marker that build-ic.sh tests to detect that it already runs inside the container. The explicit user:group form makes both podman and docker drop supplementary groups (verified with podman 4.9.3 and docker 29.5.2), so on uid-1001 hosts (GitHub runners, namespace.so devboxes) build-ic.sh re-executed container-run.sh inside the container and failed on its nesting guard. The primary group still comes from /etc/passwd.
  • test(ci): ci/container/test-container-run.sh. Runs on the host, locally or on CI, with podman (default) or CONTAINER_RUNTIME=docker. It starts containers from the checkout and from a temporary linked worktree next to it and asserts: cwd is the host path, nothing at /ic, BAZELRC unset, checkout owned by the host uid, git works in both checkouts (toplevel, common dir, HEAD, status, gc.worktreePruneExpire=never, the other worktree listed as prunable, workspace_status.sh --stamp), bazel's default output base is md5(host path) and differs per checkout, no rc file is written to the cache dir, the main checkout's bazel server keeps its pid while the worktree container runs bazel (the fix(ci): give each checkout its own bazel output base in container-run.sh #11441 regression), and build-ic.sh --help drops into the ic-build container from a repo-relative and from an absolute host path. All containers use a throwaway cache directory, so real output bases and running servers are never touched; a dirty tree is fine. About 30 s locally with warm images.
  • ci: test-container-run runs the script once per runtime (podman, docker) with fail-fast: false. The crun-pinning workaround is gated on matrix.runtime == 'podman' because container-run.sh forwards PODMAN_RUN_USR_ARGS to docker run too. .github/workflows/ci-main.yml joins the job's paths filter so edits to the job run it on the PR. The old TestCase 1/2 legs (start a container, assert nothing) are replaced; no ruleset names them.
  • docs: README subsection on the test.

Verified on a devenv: the script passes under podman and docker from the main checkout, and id inside a container now lists the user's supplementary groups.

@basvandijk basvandijk changed the title bas/test container run test(ci): add ci/container/test-container-run.sh and run it per container runtime Sep 5, 2026
@basvandijk
basvandijk requested a balanced review from Copilot September 5, 2026 14:42
@github-actions github-actions Bot added the test label Sep 5, 2026

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Changes recommended

The concurrency test can falsely pass when Bazel fails in the worktree container.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Adds integration coverage for container-run.sh across Podman and Docker while preserving supplementary container groups.

Changes:

  • Preserves supplementary groups when selecting the container user.
  • Adds worktree, Bazel isolation, and build-ic.sh integration tests.
  • Runs tests for both container runtimes in CI and documents usage.
File summaries
File Description
ci/container/test-container-run.sh Adds integration tests.
ci/container/README.md Documents the test script.
ci/container/container-run.sh Preserves supplementary groups.
.github/workflows/ci-main.yml Adds Podman and Docker test jobs.
Review details
  • Files reviewed: 4/4 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.

Comment thread ci/container/test-container-run.sh
@basvandijk
basvandijk force-pushed the bas/test-container-run branch from d096520 to 10de995 Compare September 5, 2026 16:14
Base automatically changed from bas/container-run-mount-checkout-at-host-path to master September 7, 2026 14:49
basvandijk and others added 5 commits September 7, 2026 16:49
…h finds its marker

/home/ubuntu is mode 750 in the base image and buildifier is a member of
group ubuntu precisely so that it can read the /home/ubuntu/.ic-build-container
marker that build-ic.sh tests to detect that it already runs inside the
container. The explicit `--user "$CTR_USER:$CTR_USER"` form makes both podman
and docker drop the user's supplementary groups, so on uid-1001 hosts
(GitHub runners, namespace.so devboxes) build-ic.sh could not see the marker,
re-executed container-run.sh inside the container and failed on its nesting
guard. Pass the user by name only; the primary group still comes from
/etc/passwd.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
An integration test for container-run.sh that can run locally and on CI. It
starts containers from the checkout and from a temporary linked worktree
next to it and asserts that the checkout is mounted at its host path and is
the working directory, that nothing is mounted at /ic and no BAZELRC is
injected, that git works in both checkouts with gc.worktreePruneExpire=never,
that bazel's default output base is md5(host path) and differs per checkout,
that the main checkout's bazel server survives a bazel run from the other
checkout, and that build-ic.sh drops into the ic-build container from both a
repo-relative and an absolute host path.

All containers use a throwaway cache directory so the developer's real
output bases and running servers are never touched.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
The test-container-run job only started a container without asserting
anything, and never exercised the docker code path of container-run.sh.
Run ci/container/test-container-run.sh once with podman and once with
docker instead. The crun-pinning workaround is podman-only: container-run.sh
forwards PODMAN_RUN_USR_ARGS to `docker run` as well, where
`--runtime /usr/local/bin/crun` is not a valid runtime. The job's own
workflow file joins the paths filter so that edits to the job run it on the
PR instead of only on master.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
…oncurrency check

The worktree container's command ended with `touch`, so a failed or timed-out
`bazel version` still exited 0 and the concurrency check could pass without
bazel ever running in the second checkout. Propagate bazel's exit status and
signal the waiting main container from the host regardless of the result.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
@basvandijk
basvandijk force-pushed the bas/test-container-run branch from c8c2c60 to 5dde06a Compare September 7, 2026 14:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants