ci(darwin tart): export RUSTUP_HOME/CARGO_HOME in the guest job environment

[robobun]

test/js/third_party/grpc-js/test-tonic.test.ts fails on every run of the darwin 14 aarch64 - test-bun lane since the tart agents came online (#37633), e.g. main builds 92687 and 92739:

error: tonic server exited (1) before reporting an address:
error: rustup could not choose a version of cargo to run, because one wasn't specified explicitly, and no default is configured.

Cause

That lane is served by the tart guests (darwin-arm64-{challah,ciabatta,focaccia,sourdough}-tart-15-*). scripts/bootstrap.sh installs rustup into /opt/rust (RUSTUP_HOME=CARGO_HOME=/opt/rust) and exports those two variables from the login profile. scripts/darwin-ci/guest/job.sh is run as a plain /bin/bash ~/job.sh, so the profile is never sourced; it puts /opt/rust/bin on PATH by hand but not the two variables. Bun.which("cargo") therefore finds the rustup proxy, and the proxy looks for a toolchain in ~/.rustup, which does not exist in the guest.

Checked inside a running guest on darwin-arm64-focaccia: /opt/rust/settings.toml has default_toolchain = "stable-aarch64-apple-darwin", cargo --version with job.sh's environment fails with the message above, and the same command with RUSTUP_HOME=/opt/rust CARGO_HOME=/opt/rust prints cargo 1.97.1. The bare agents are unaffected because scripts/agent.mjs runs jobs with sh -elc, which sources the profile; that is why the darwin 26 aarch64 lane passes.

Fix

Export RUSTUP_HOME and CARGO_HOME in job.sh next to the PATH line that already hardcodes /opt/rust/bin.

The test itself is left alone: it fails loudly on purpose (#33970), and that is what surfaced this.

Rollout

The hosts run the copy of job.sh installed in /usr/local/share/darwin-ci at provision time (command.ts pushes it into the guest per job), so this PR's own darwin 14 lane will still show the failure. The four tart hosts need the updated file copied into place (no agent restart needed; the next job picks it up), or a re-run of main.ts provision.

cc @alii

---

no test proof · iteration 0 · build/CI scripts only; test-proof not applicable

[robobun]

^{Updated 9:05 PM PT - Aug 11th, 2026}

@robobun, your commit 2957b27 is building: #92771

[coderabbitai]

Warning

Review limit reached

@robobun, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 18 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: f90270ac-63a5-4e8a-bdea-7d9818e5a455

📥 Commits

Reviewing files that changed from the base of the PR and between 6596bf1 and 2957b27.

📒 Files selected for processing (1)

• scripts/darwin-ci/guest/job.sh

---

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

[robobun]

Status: reproduced and fixed in job.sh.

• Reproduced inside a running tart guest on darwin-arm64-focaccia: cargo --version with job.sh's environment fails with rustup could not choose a version of cargo to run; the same command with RUSTUP_HOME=/opt/rust CARGO_HOME=/opt/rust prints cargo 1.97.1.
• The darwin 14 lane on this PR will still fail test-tonic.test.ts: the hosts run the job.sh installed under /usr/local/share/darwin-ci, not the one in the checkout. It goes green once the four tart hosts have the updated file.

[claude]

LGTM — two-variable env export in the tart guest job wrapper.

What was reviewed:

• Confirmed scripts/bootstrap.sh:1323-1326 installs rustup to /opt/rust and only writes RUSTUP_HOME/CARGO_HOME to the login profile.
• Confirmed hooks/command.ts:65 invokes /bin/bash ~/job.sh (non-login), so the profile is never sourced — matches the stated cause.
• Placement before source ~/job.env means a job can still override; no interaction with set -u or the rest of the script.

Extended reasoning...

Overview

The PR adds a single export RUSTUP_HOME=/opt/rust CARGO_HOME=/opt/rust line (plus a two-line comment) to scripts/darwin-ci/guest/job.sh, the per-job entrypoint that runs inside macOS tart guest VMs. The existing script already hardcodes /opt/rust/bin in PATH; this adds the two companion variables that rustup needs to locate its toolchain state.

Security risks

None. This is CI-only shell plumbing that sets two environment variables to a fixed literal path inside an ephemeral guest VM. No runtime code, no user-facing surface, no secrets.

Level of scrutiny

Low. It is a three-line infra change to a CI wrapper script, mirroring values that scripts/bootstrap.sh already writes to the login profile. I verified the two supporting claims directly: bootstrap.sh sets rust_home=/opt/rust and appends both exports via append_to_profile, and hooks/command.ts launches the script with plain /bin/bash ~/job.sh rather than a login shell, so those profile exports are never seen. The fix is the minimal, localized way to close that gap and sits immediately next to the existing /opt/rust/bin PATH entry it complements.

Other factors

The export is placed before set -a; source ~/job.env, so per-job env can still override it, and it does not interact with set -u or the rest of the script. The PR description already flags that the fix will not self-verify in this PR's own darwin 14 lane because hosts run the provisioned copy of job.sh — that is an expected rollout property, not a defect in the change. No prior reviewer comments to address.