ci/build.sh leaves host target/ root-owned after local runs #2

New issue

Open

opened 2026-08-06 08:55:24 +08:00 by Breadway · 0 comments

Breadway commented

2026-08-06 08:55:24 +08:00

Owner

ci/build.sh runs the shared CI container via docker run with no --user flag, so the container's default user is root:

docker run --rm \
    -v "${REPO_ROOT}:/workspace" \
    ...
    "bread-ci:${PRODUCT}" \
    bash -c '
        set -euo pipefail
        "$@"
        mkdir -p /workspace/target
        cp -a /cargo-target/. /workspace/target/
    ' bash "$@"

The final cp -a /cargo-target/. /workspace/target/ step writes directly onto the host bind-mount (-v "${REPO_ROOT}:/workspace") as root, so every local invocation of ci/build.sh leaves the product repo's target/ owned by root:root on the host afterward. Any later host-side cargo invocation (e.g. cargo clippy) then fails with a permission error on target/debug/.cargo-build-lock until someone manually chowns it back.

Found this while running a clippy pass across the ecosystem on 2026-08-06 — root-owned target/ blocked builds in breadmon, breadshot, breadclip, and breadpad (all had to be chown'd back to the invoking user before cargo clippy would run). Likely affects every product wired up to ci/build.sh (breadbar's CI just got ported onto it per #4) the first time it's run locally rather than in the actual CI runner.

Fix: pass --user "$(id -u):$(id -g)" to docker run (works fine since the container only needs write access to the named cargo-cache volumes and the bind-mounted workspace, both already host-writable), or chown the copied files back to the invoking user's uid/gid as the last step before the container exits.

`ci/build.sh` runs the shared CI container via `docker run` with no `--user` flag, so the container's default user is root: ```sh docker run --rm \ -v "${REPO_ROOT}:/workspace" \ ... "bread-ci:${PRODUCT}" \ bash -c ' set -euo pipefail "$@" mkdir -p /workspace/target cp -a /cargo-target/. /workspace/target/ ' bash "$@" ``` The final `cp -a /cargo-target/. /workspace/target/` step writes directly onto the host bind-mount (`-v "${REPO_ROOT}:/workspace"`) as root, so every local invocation of `ci/build.sh` leaves the product repo's `target/` owned by `root:root` on the host afterward. Any later host-side `cargo` invocation (e.g. `cargo clippy`) then fails with a permission error on `target/debug/.cargo-build-lock` until someone manually `chown`s it back. Found this while running a clippy pass across the ecosystem on 2026-08-06 — root-owned `target/` blocked builds in breadmon, breadshot, breadclip, and breadpad (all had to be `chown`'d back to the invoking user before `cargo clippy` would run). Likely affects every product wired up to `ci/build.sh` (breadbar's CI just got ported onto it per #4) the first time it's run locally rather than in the actual CI runner. Fix: pass `--user "$(id -u):$(id -g)"` to `docker run` (works fine since the container only needs write access to the named cargo-cache volumes and the bind-mounted workspace, both already host-writable), or `chown` the copied files back to the invoking user's uid/gid as the last step before the container exits.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Breadway/bread-ecosystem#2

No description provided.

Rows
Columns