Compare commits

..

1 Commits

Author SHA1 Message Date
4a8f1221b2 fix(ci): run the container as the invoking user, not root
Docker on the dev boxes is rootful, so without `--user` every byte the build
writes into the bind-mounted repo is owned by root and the user needs `sudo` to
delete their own artifacts. This is not hypothetical: `export/` in a working
tree held 227 root-owned paths (149 MB) from earlier runs, and the `sylpheed.db`
regen in the workspace CLAUDE.md writes straight into /work, so it lands
root-owned every time.

The catch is that the daemon creates a named volume root-owned, so a `--user`
container cannot write /cargo or /target at all. So take ownership of both
volumes first -- once, and only when it is actually wrong, since a recursive
chown across a ~36 GB target volume is not something to repeat per invocation.
Both are sampled, not just one, because an older run can leave them drifted.

Volume names become overridable (SYLPH_CI_CARGO_VOL / SYLPH_CI_TARGET_VOL),
which is what let the chown path be tested without touching the real caches.

Placed above the corpus-mount block so it does not collide with #53.

Measured, not assumed:
  * fresh root-owned volumes  -> chowns once, then writes as uid 1000
  * second run                -> no chown, correctly cached
  * `cargo check -p sylpheed-ppc` through the runner -> passes, exit 0
  * a file touched in /work   -> owned fabi:fabi, removable without sudo

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-18 21:30:29 +02:00
2 changed files with 40 additions and 27 deletions

View File

@@ -31,24 +31,6 @@ env:
# So: one job, on the machine that exists, building for the machine that exists.
# If a second architecture is ever wanted here it needs a second RUNNER, not a
# second matrix row.
#
# ── The toolchain is PINNED, in three places, deliberately ───────────────────
#
# All three jobs used `dtolnay/rust-toolchain@stable`, which resolves to whatever
# stable is on the day the job runs. A lint gate that floats is not a gate: the
# same tree goes green or red depending on the date, and this repo has already
# produced a disagreement between two people reading the same commit (#15).
# `collapsible_else_if` is the example — `warn` on 1.92.0, `allow`-by-default
# pedantic on 1.98.1, so a clean local run and a red CI run were both correct.
#
# `1.98.1` is the version run 206 resolved, and `docker/ci/Dockerfile` pins the
# same one, so `docker/ci/run cargo clippy …` on a desktop is a true stand-in for
# this workflow rather than an approximation of it.
#
# To bump: change all three `dtolnay/rust-toolchain@` refs here AND the `FROM
# rust:<version>-bookworm` in `docker/ci/Dockerfile` in one commit, so the two
# can never drift apart silently. A bump is a change to the gate and belongs in
# its own PR, where the new lints it turns on are the diff.
jobs:
# ── Native build, on the one runner there is ────────────────────────────────
@@ -60,15 +42,13 @@ jobs:
- uses: actions/checkout@v4
- name: Install Rust toolchain
# Pinned — see the toolchain note at the top of this file.
#
# This action installs a MINIMAL profile: rustc, cargo, rust-std and no
# `stable` installs a MINIMAL profile: rustc, cargo, rust-std and no
# more. Components have to be named. Without this line the Clippy step
# below dies on "'cargo-clippy' is not installed for the toolchain
# 'stable-aarch64-unknown-linux-gnu'" — which is not a lint result, it
# is the step never having run. The `fmt` job below always got this
# right; this one never did.
uses: dtolnay/rust-toolchain@1.98.1
uses: dtolnay/rust-toolchain@stable
with:
components: clippy
@@ -98,7 +78,7 @@ jobs:
run: cargo test --workspace
# The tally above cannot tell you what it verified. `cargo test` reports
# the same count whether the disc corpus was exercised or entirely
# the same 207/0/14 whether the disc corpus was exercised or entirely
# absent -- a gated suite that skips still counts as passed, and the
# `ignored` column is a static count of `#[ignore]` attributes that cannot
# move at runtime. Issue #16. This prints what the run ACTUALLY had, from
@@ -134,7 +114,7 @@ jobs:
- uses: actions/checkout@v4
- name: Install Rust toolchain + WASM target
uses: dtolnay/rust-toolchain@1.98.1
uses: dtolnay/rust-toolchain@stable
with:
targets: wasm32-unknown-unknown
@@ -181,7 +161,7 @@ jobs:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: dtolnay/rust-toolchain@1.98.1
- uses: dtolnay/rust-toolchain@stable
with:
components: rustfmt
- run: cargo fmt --all -- --check

View File

@@ -21,18 +21,51 @@ IMAGE="${SYLPH_CI_IMAGE:-sylph-ci:local}"
CPUS="${SYLPH_CI_CPUS:-6}"
MEM_GB="${SYLPH_CI_MEM_GB:-7}"
CARGO_VOL="${SYLPH_CI_CARGO_VOL:-sylph-ci-cargo}"
TARGET_VOL="${SYLPH_CI_TARGET_VOL:-sylph-ci-target}"
# 🔴 Docker on the dev boxes is ROOTFUL, so without `--user` every byte the build
# writes into the bind-mounted repo is owned by root — and the user then needs
# `sudo` to delete their own artifacts. The regen command in the workspace
# `CLAUDE.md` writes `sylpheed.db` straight into /work, so it lands root-owned,
# and a stray root-owned file is exactly what survived the last cleanup and had
# to be sudo'd away.
#
# The catch is that the daemon creates a named volume root-owned, so a `--user`
# container cannot write /cargo or /target at all. Take ownership once — and
# only when it is actually wrong, because a recursive chown across a ~36 GB
# target volume is not something to repeat on every invocation.
RUN_UID="$(id -u)"
RUN_GID="$(id -g)"
docker volume create "$CARGO_VOL" >/dev/null
docker volume create "$TARGET_VOL" >/dev/null
# Both volumes, not just one: they are chowned together but can drift apart if an
# older root-owned run created only one of them.
vol_owner="$(docker run --rm -v "$CARGO_VOL:/cargo" -v "$TARGET_VOL:/target" "$IMAGE" \
stat -c %u /cargo /target 2>/dev/null | sort -u | tr '\n' ' ' || echo unknown)"
if [ "$vol_owner" != "$RUN_UID " ]; then
echo "docker/ci/run: chowning the cargo/target volumes to $RUN_UID:$RUN_GID (one-off)" >&2
docker run --rm \
-v "$CARGO_VOL:/cargo" -v "$TARGET_VOL:/target" \
"$IMAGE" chown -R "$RUN_UID:$RUN_GID" /cargo /target
fi
args=(
--rm
--cpus "$CPUS"
--memory "${MEM_GB}g"
--memory-swap "${MEM_GB}g"
--pids-limit 2048
# Run as the invoking user so build output in /work is owned by them, not root.
--user "$RUN_UID:$RUN_GID"
-v "$REPO:/work"
# Named volumes, not bind mounts: the host tree keeps a 32 GB `target/` from
# earlier host-side builds, and mixing the two produces rebuilds that look
# like cache misses and are actually two toolchains fighting over one directory.
-v sylph-ci-cargo:/cargo -e CARGO_HOME=/cargo
-v sylph-ci-target:/target -e CARGO_TARGET_DIR=/target
-v "$CARGO_VOL:/cargo" -e CARGO_HOME=/cargo
-v "$TARGET_VOL:/target" -e CARGO_TARGET_DIR=/target
-w /work
)