[jdx]

Summary

• keep the cache-session fixture’s Cargo home and target directory inside its permitted target/ sandbox path
• prevent fresh CI containers from failing when Cargo creates its global cache lock files

Context

The E2E failure seen on #11857 was unrelated to the install-hook change. cargo build creates .global-cache, .package-cache, and .package-cache-mutate in CARGO_HOME even for the dependency-free fixture. On fresh CI containers, those files do not exist yet and the task’s deny_write = true sandbox rejects their creation outside allow_write = ["target"].

Testing

• mise run lint-fix
• e2e/run_test tasks/test_task_action_cache_session
• repeated the focused test with a fresh external CARGO_HOME; the fixture now succeeds because it scopes Cargo writes to target/

AI-assisted — Tool: Codex; model: unavailable/unavailable; version: unavailable.

---

Note

Low Risk
E2E fixture-only change; no production task-cache or sandbox behavior is modified.

Overview
Fixes the cache-session E2E compile task so cargo build no longer writes outside the sandbox.

The task uses deny_write = true with allow_write = ["target"], but plain cargo build still creates lock/cache files under the default CARGO_HOME, which fails on fresh CI. The run script now sets CARGO_HOME=target/cargo-home and CARGO_TARGET_DIR=target so all Cargo writes stay under the permitted target/ path.

^{Reviewed by Cursor Bugbot for commit 3fc941c. Bugbot is set up for automated code reviews on this repo. Configure here.}

Summary by CodeRabbit

• Bug Fixes
  • Improved compile task caching by storing Cargo build data within the project’s target directory.
  • Preserved existing build verification behavior.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited), Organization UI (inherited)

Review profile: CHILL

Plan: Pro Plus

Run ID: 04f77260-65b8-460e-a6c7-45956e7063ea

📥 Commits

Reviewing files that changed from the base of the PR and between 566f807 and 3fc941c.

📒 Files selected for processing (1)

• e2e/tasks/test_task_action_cache_session

---

📝 Walkthrough

Walkthrough

The compile task now places Cargo home and target data under target before running cargo build. Existing build verification remains unchanged.

Changes

Cargo sandbox isolation

Layer / File(s)	Summary
Configure Cargo paths e2e/tasks/test_task_action_cache_session	The compile task redirects Cargo home and target directories into target before the build.

Estimated code review effort: 2 (Simple) | ~5 minutes

Possibly related PRs

• jdx/mise#11763: Both changes isolate Cargo data in task-cache session and Rust action-cache behavior.
• jdx/mise#11861: Both changes modify the compile task in e2e/tasks/test_task_action_cache_session.

Poem

A rabbit hops where Cargo writes,
Beneath target, it stays in sight.
Builds still check the same bright way,
No stray files escape today.
Sproing! Sandbox paths are neat.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: isolating Cargo writes within the cache-session E2E test.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Greptile Summary

The PR keeps Cargo’s home and target output beneath the cache-session fixture’s permitted target/ sandbox.

• Sets CARGO_HOME to target/cargo-home.
• Sets CARGO_TARGET_DIR explicitly to target.
• Documents why Cargo’s cache-lock writes must remain inside the allowed path.

Confidence Score: 5/5

The PR appears safe to merge with no actionable defects identified.

The changed Cargo environment paths remain inside the permitted sandbox, preserve the asserted build artifact location, and do not add Cargo home contents to task or Rust action-cache artifacts.

Important Files Changed

Filename	Overview
e2e/tasks/test_task_action_cache_session	Redirects Cargo’s cache and build writes into the sandbox-approved target directory without changing the fixture’s expected artifact path or cache assertions.

_{Reviews (1): Last reviewed commit: "test(task): isolate cargo writes in cach..." | Re-trigger Greptile}

[github-actions]

Instruction counts

benchmark	trend	instructions	Δ	wall (min)	Δ
env	▄▆▅▂▁▄▅▃▁▃▅█	76,631,979 → 76,679,404	+0.06%	18.72 → 18.47ms	-1.34%
hook-env	█▄▆▇▅▆▁▂▃▃▃▁	78,119,783 → 78,091,889	-0.04%	18.36 → 19.17ms	+4.41%
ls	▄▄▄▆▂▃▃▁▂▃▃█	69,320,044 → 69,421,908	+0.15%	16.31 → 16.37ms	+0.40%
registry	▄▂▄▁▅▅▆▆▆▆█▅	49,079,276 → 49,001,868	-0.16%	13.18 → 12.06ms	-8.46%
startup	████▃▂▁▁▁▁▃▄	15,515,732 → 15,519,870	+0.03%	9.43 → 9.01ms	-4.42%

No instruction-count regression above 1%.

_{Only instruction counts gate. Wall clock is shown for context — on identical hardware it moves 4-20% run to run.}

_{Measured by tak — instruction-counted CLI benchmarks, stored in this repository's git notes.}

_{3fc941c18bd9 vs 566f80744257 · measured on the runner, not pushed to the history.}

[JamBalaya56562]

The e2e run on this PR's head (3fc941c1) still fails the fixture it targets, on both retry attempts:

##[error][mise run compile 2>&1] command failed with status 1
##[error]tasks/test_task_action_cache_session

https://github.com/jdx/mise/actions/runs/31453472371/job/93663096515

The reason is that cargo build never starts. Landlock is unavailable on these runners, so apply_landlock bails inside the pre_exec hook, before execve:

mise sandbox: failed to apply landlock restrictions: RestrictionStatus { ruleset: NotEnforced,
no_new_privs: true, landlock: NotEnabled, log_same_exec: true, log_new_exec: false,
log_subdomains: true, all_threads: false }

https://github.com/jdx/mise/actions/runs/31449920970/job/93652822330 — an e2e job carrying an extra diagnostic print I had on #11853. landlock: NotEnabled is the runner's own report. restrict_self() comes back NotEnforced, the check at the end of apply_landlock bails, and the child dies before exec. Nothing writes anywhere, so where Cargo would have put its lock files does not come into it.

The failure mode described here is real, just conditional on Landlock working. e2e/run_test:43 resolves CARGO_HOME from the outer $HOME before HOME is swapped for the isolated one, so the default lands outside /tmp, and the deny_write-only branch of apply_landlock grants only / (read), /tmp, /dev and allow_write. Where Landlock is enabled, scoping Cargo under target/ does fix it. Where it is NotEnabled, there is nothing to fix at that layer.

#11861 takes the other route — drop deny_write/allow_write from the fixture. Its e2e is green on the same runners (PASS: tasks/test_task_action_cache_session, https://github.com/jdx/mise/actions/runs/31457042598/job/93673507583), and every check on the PR passes.

The coverage that gives up is smaller than it looks. The isolated dir lives under /tmp — /tmp/test_task_action_cache_session.* in the logs above — and the deny_write branch grants /tmp full access, so the fixture's own writes (target/, config, cache) were never constrained. The only write the sandbox actually denied was Cargo's CARGO_HOME, which is not what a task-action-caching test asserts.

Either way is fine by me. The two changes are not exclusive: yours makes the fixture pass wherever Landlock works, and if you would rather keep the sandbox here I can close #11861 — the runners would then need Landlock for this to go green.

On why this sat unnoticed: the e2e workflow runs two tranches in a single command: and keeps only the second exit code, so failures in tranches 0-3 are discarded. I have three runs where this fixture failed and the job still reported success. #11853 fixes the aggregation and is what surfaced it.