Install Rust explicitly in the development version tests - #211
Conversation
Occasionally, the development version tests will fail because the runner uses an image that does not include a Rust compiler. This is an attempt at fixing that issue. This is based on Qiskit/qiskit#16731.
Coverage Report for CI Build 32529557299Warning Build has drifted: This PR's base is out of sync with its target branch, so coverage data may include unrelated changes. Coverage remained the same at 96.524%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsNo coverage regressions found. Coverage Stats
💛 - Coveralls |
The intermittent development-version failures are not caused by the
runner image lacking a Rust compiler -- rustup is present on all of the
relevant images. What actually happens is visible in the failing logs,
partway through `python -m build --wheel`:
running build_rust
info: syncing channel updates for 1.87-x86_64-unknown-linux-gnu
info: recovering from a partially installed toolchain
info: removing previous version of component rustc
...
error: failed to install component:
'clippy-preview-x86_64-unknown-linux-gnu',
detected conflict: 'bin/cargo-clippy'
error: can't find Rust compiler
Qiskit's rust-toolchain.toml pins a channel and requests `clippy` and
`rustfmt` as components, so setuptools-rust triggers an on-demand rustup
install of that toolchain. When the runner image already carries a
partially-installed copy of it, rustup's recovery path removes `rustc`
and then aborts on a `bin/cargo-clippy` conflict, leaving no compiler
behind. The "can't find Rust compiler" line is the symptom, not the
cause, which is why the failure looked like a missing toolchain. It is
intermittent because it depends on which runner image generation the job
lands on.
The previous version of this step could not help, because
`rustup toolchain install` with no toolchain argument installs the
*active* toolchain, and "active" depends on the working directory:
$ cd /tmp # no rust-toolchain.toml in scope
$ rustup show active-toolchain
stable-x86_64-unknown-linux-gnu (default)
$ cd qiskit
$ rustup show active-toolchain
1.89-x86_64-unknown-linux-gnu (overridden by '.../rust-toolchain.toml')
That step ran before the clone existed, so it installed `stable` while
the build went on to need the pinned channel. This differs from
Qiskit/qiskit#16731, which this was based on: there, every such step runs
inside a checkout of the repository that owns rust-toolchain.toml, so the
bare command resolves the pinned toolchain. Here the toolchain-defining
repository is a nested clone created mid-job, so the same command means
something different.
So split the clone into its own step and run the installation inside it,
first uninstalling the pinned channel to clear any partial copy. The
uninstall is what addresses the conflict; it is a no-op (exit 0) when
nothing is installed. Note that `--force` does *not* help here, despite
being documented as forcing an update -- it still aborts on the same
component conflict.
`--profile minimal` is retained. It does not suppress the `clippy` and
`rustfmt` components that rust-toolchain.toml requests explicitly, but it
does drop `rust-docs`, which rustup would otherwise download for a job
that never reads it.
Verified locally by reproducing the exact CI error against a staged
partial toolchain, and confirming the new sequence recovers from it.
|
This comment was generated by Claude Opus 5 under my guidance. I went back through the failing logs across the addon repos before pushing 473f075, and the diagnosis in the original PR description turns out to be wrong in a way that made the fix a no-op. Summarizing here for the record. The failure is not a missing Rust compilerOver the last ~100 development-version runs, the All 9 are the same failure, and rustup is present on the image: Qiskit's Why the original step couldn't help
$ cd /tmp # no rust-toolchain.toml in scope
$ rustup show active-toolchain
stable-x86_64-unknown-linux-gnu (default)
$ cd qiskit
$ rustup show active-toolchain
1.89-x86_64-unknown-linux-gnu (overridden by '.../rust-toolchain.toml')The step ran before This is the structural difference from Qiskit/qiskit#16731: there, those steps run inside a checkout of the repo that owns What changedClone is now its own step, and the install runs inside it, preceded by an uninstall of the pinned channel to clear any partial copy. The uninstall is the part that actually addresses the conflict, and it's a no-op (exit 0) when nothing is installed. Two findings worth recording, both from testing rather than reasoning:
Verification and caveatI reproduced the exact CI error locally by staging a partial toolchain (a stray The caveat: this failure depends on runner-image state, so green CI on this PR is not evidence of a fix — the last several weeks are green everywhere, including on Since these repos share this workflow, it's probably worth propagating once we're satisfied — the failures cluster in sqd/obp/mpf/aqc-tensor rather than here. |
2 participants
Occasionally, the development version tests will fail because the runner uses an image that does not include a Rust compiler. This is an attempt at fixing that issue.
This is based on Qiskit/qiskit#16731.