Skip to content

fix(ci): install Rust via rustup on the self-hosted ADF lane - #971

Open
AlexMikhalev wants to merge 4 commits into
mainfrom
task/ci-adf-rust-install-gh
Open

AlexMikhalev wants to merge 4 commits into
mainfrom
task/ci-adf-rust-install-gh

Conversation

@AlexMikhalev

@AlexMikhalev AlexMikhalev commented Oct 9, 2026 •

Copy link
Copy Markdown
Contributor

Problem

The nightly ADF Agent Validation workflow failed on every scheduled run since 4 October (9 consecutive failures, latest 37907419012). Two independent faults, the second hidden behind the first.

1. Unresolvable action

The job died during "Prepare all required actions", before any Rust step ran:

##[error]Unable to resolve action dtolnay/rust-action, repository not found

dtolnay/rust-action does not exist. Install through rustup instead, matching the pattern release-lsp.yml already uses on its self-hosted lane. Pinned to 1.96 to follow the repo root rust-toolchain.toml (fleet standard, ADR-0006); stable would drift from that pin.

2. kache missing from PATH

With the action fixed, the build died:

error: could not execute process `kache /home/alex/.rustup-runner-5/toolchains/1.96.../bin/rustc -vV` (never executed)
Caused by: No such file or directory (os error 2)

The host sets rustc-wrapper = "kache" in ~/.cargo/config.toml and the kache daemon runs, but the binary lives in ~/.local/bin, which the terraphim-ai runner .env omits:

PATH=/home/alex/.cargo-runner-5/bin:/home/alex/.rustup-runner-5/toolchains/stable-.../bin:/usr/local/bin:/usr/bin:/bin

The terraphim-ai runners are configured without that directory; the wrapper therefore cannot be found even though the binary is installed and the daemon runs.

Fix the PATH, not the wrapper. Adding ~/.local/bin via GITHUB_PATH lets the existing wrapper resolve and keeps kache's content-addressed cache. Clearing RUSTC_WRAPPER would also get past the error but would discard the cache the wrapper exists to provide, slowing every self-hosted build. That approach was tried and rejected.

Change

- name: Install Rust
  run: |
    rustup toolchain install 1.96 --profile minimal --component rustfmt,clippy
    rustc --version
    cargo --version

- name: Put the kache build cache on PATH
  run: |
    echo "${HOME}/.local/bin" >> "$GITHUB_PATH"
    "${HOME}/.local/bin/kache" --version

Verification

Dispatched the workflow on this branch and the job ran green end to end:

Step Result
Install Rust success
Put the kache build cache on PATH success
Build adf binary success
Run agent validation (all modes) success
Upload validation report success
Parse and display results success

Before the fix, the action step failed within seconds. Two intermediate runs pinned down the second fault: 37978805868 (build failed on kache) and 37979446951 (my initial PATH step called kache before GITHUB_PATH took effect — that applies from the next step).

Mirrored

terraphim/terraphim-ai#3478 on Gitea carries the same squashed change; the file is identical on both lines.

Follow-up not in scope

terraphim/gitea-robot #70 reports the same class of problem wider: workflows request ubuntu-latest while only terraphim-native is registered. Separately, other workflows on these same runners may hit the kache PATH fault; a per-workflow PATH step is the portable fix, since the runner .env is managed outside the repo.

forge-admin added 4 commits October 9, 2026 21:13
The nightly ADF Agent Validation workflow has failed on every scheduled
run since 4 October. The job dies during "Prepare all required actions"
with "Unable to resolve action dtolnay/rust-action, repository not
found": the action does not exist.

Install the toolchain through rustup instead, matching the pattern
release-lsp.yml already uses on its self-hosted lane. The runners share
a kache-backed CARGO_HOME whose build dir holds read-only hard-linked
artefacts, so a third-party toolchain action that injects its own cache
and rustc wrapper fights that setup.

Pin 1.96 rather than stable: the repo root rust-toolchain.toml pins
channel 1.96 (fleet standard, ADR-0006), and installing stable would
drift from that pin and rewrite the shared stable toolchain on the host.
The pin already selects the toolchain, so no rustup override is set.

Verified the step's commands under the runner's real environment
(RUSTUP_HOME=/home/alex/.rustup-runner-2a): the install is a no-op,
exit 0, with rustfmt and clippy present, and rustc/cargo resolve to
1.96.1.
The verification run on this branch (37978805868) proved the rustup
install works: "Install Rust" now succeeds and the job advances past
the action-resolution failure. It then died in "Build adf binary":

    error: could not execute process `kache .../bin/rustc -vV`
    (never executed)
    Caused by: No such file or directory (os error 2)

The runner host sets rustc-wrapper = "kache" in ~/.cargo/config.toml,
and kache is not on the runner PATH. release-lsp.yml clears
RUSTC_WRAPPER and RUSTC_WORKSPACE_WRAPPER on its self-hosted lane for
exactly this reason; do the same here, before the build step.
The prior commit cleared RUSTC_WRAPPER to get past the build failure.
That is the wrong fix: it discards kache's content-addressed cache,
which is the reason the wrapper is configured in the first place, and
slows every self-hosted build.

The real fault is PATH. kache lives in ~/.local/bin and works fine
(v0.12.0, daemon active, wrapper executes), but the terraphim-ai runner
.env sets a PATH without that directory:

  PATH=/home/alex/.cargo-runner-5/bin:
       /home/alex/.rustup-runner-5/toolchains/stable-.../bin:
       /usr/local/bin:/usr/bin:/bin

Compare the zestic runner, which does include ~/.local/bin.

Add ~/.local/bin via GITHUB_PATH so the existing rustc-wrapper resolves
and the build keeps the cache. Drop the wrapper-clearing step.
The previous commit failed at run 37979446951 with "kache: command not
found" (exit 127). The PATH write was correct; the verification line
ran in the same step, and GITHUB_PATH only affects subsequent steps.
Call the binary by absolute path for the assertion.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant