Repository navigation
ci: install the pinned toolchain's components in the retried step - #797
Conversation
rust-toolchain.toml pins 1.96.0 with rustfmt and clippy. Most jobs installed 1.96.0 through dtolnay/rust-toolchain with a narrower component set, so the first cargo command in a later run step made rustup fetch the channel manifest and the missing components. That implicit download has no retry, and a transient failure of static.rust-lang.org failed the job (for example "could not download file from .../channel-rust-1.96.0.toml.sha256" in the Edict provider verifier job). Every 1.96.0 install step now names both components, so the download happens in the action, which retries, and run steps need no network for the toolchain. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info
📝 Walkthrough
Merge Risk: ⚪ Minimal · up to
|
| Check name | Status | Explanation |
|---|---|---|
| Description Check |  |
Check skipped - CodeRabbit’s high-level summary is enabled. |
| Title check | |
The title accurately summarizes the main change: installing the pinned Rust toolchain components in CI steps that can be retried. |
| Docstring Coverage | |
No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0… |
| Linked Issues check | |
Check skipped because no linked issues were found for this pull request. |
| Out of Scope Changes check | |
Check skipped because no linked issues were found for this pull request. |
✨ Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Commit to this branch
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
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.
Comment @coderabbitai help to get the list of available commands.
The previous commit duplicated a components key in echo-keep-experimental.yml, which already named both components, and indented the new keys inconsistently in the two-space workflow files. Restore the first and correct the others. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dfe0a7668f
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Address review: the first pass matched only steps written as a list item and missed the six named steps in det-gates.yml. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…toolchain-components
1 participant
What changes
rust-toolchain.tomlpins 1.96.0 withrustfmtandclippy. Most jobs installed 1.96.0 throughdtolnay/rust-toolchainwith a narrower component set (often none). The firstcargocommand in a laterrunstep then made rustup sync the channel manifest and install the missing components. That implicit download has no retry.Observed on #791: the Build and check Edict provider verifier job failed in its
cargo xtaskstep withalthough the job had installed 1.96.0 two steps earlier (
cargo,rust-std,rustconly).Every step that installs 1.96.0 now names both components: 32 steps across seven workflows, of which one already did. The download happens inside the action, which retries, and
runsteps need no network for the toolchain. No job installs anything it was not already installing implicitly.Evidence
The failing log lines above are from run 38349154351. This PR's own checks exercise the change; the thing to look for is that no
runstep printssyncing channel updates for '1.96.0-...'.Limits
This removes one source of the flake, the one seen. A download failure inside the action after its retries, or a crates.io or container-registry failure, can still fail a job.
🤖 Generated with Claude Code
Summary by CodeRabbit