Extra rust toolchain components are sometimes randomly available and other times are missing

[Veetaha]

Hi! I'm very grateful for this Github action, and I've been loving it ever since ❤. Today, though I stumbled with a problem.

I'm running a regular daily CI in the repo elastio/bon to catch sudden regressions not related to code changes. For the last week every CI run was fine except some weird things started to happen since May 13, 2025. The CI history is public here:

CI was green every day until the first failure on May 13, 2025. There were no code changes in the repo for the last two weeks.

Copying the CI output for history (because github deletes old CI logs very aggressively):

Run cargo clippy --all-features --all-targets --locked
error: 'cargo-clippy.exe' is not installed for the toolchain '1.86.0-x86_64-pc-windows-msvc'.
To install, run `rustup component add --toolchain 1.86.0-x86_64-pc-windows-msvc clippy`

I figured that this was because I just missed adding the explicit clippy and rustfmt components (rustfmt problem suddenly revealed itself in another CI run) parameters in some of the CI jobs, which I fixed in this commit and CI became green after that.

The rust-toolchain.toml is structured like this and it never ever mentioned any extra clippy or rustfmt components (note: I've just bumped the version to 1.87.0 in master):

[toolchain]
channel    = "1.86.0"
components = ["cargo"]

However, the problem is "Why was it green in the first place"? The should've been failing all this time. However, my CI config missed the clippy in this job for example, and I haven't seen a failure for 7 months (that job always used clippy):

But this problem started showing itself only today.

[jonasbb]

That is an interesting issue that lead to quite a chase :D

As best as I can tell, with rustup 1.28.2 the behavior changed how it installs from rust-toolchain.toml files. It used to use the default profile (thus providing clippy etc.) but with 1.28.2 it reads the profile from ~/.rustup/settings.toml, which on GitHub Actions is minimal.

This change in rustup behavior is not called out in the changelog and I reported it (https://github.com/rust-lang/rustup/issues/4337).

The new rustup comes from the GitHub Actions image update that happened five days ago (2025-05-12), so just before your CI runs started failing. This is how I found this PR to change the default profile in the GitHub Actions images (https://github.com/actions/runner-images/pull/12214). This is actually where I got the information about this behavior change from. It points the blame at this commit https://github.com/rust-lang/rustup/commit/f439f4837650703f17e63d3b58011218b18eb07c

[Veetaha]

Thank you for looking into this!

I'm trying to understand what the expected behavior and further changes here should be. From what I see:

• The change in rustup was unintentional and will be reverted according to https://github.com/rust-lang/rustup/issues/4337#issuecomment-2888297467
• This means the PR https://github.com/actions/runner-images/pull/12214 won't make sense for the next versions of rustup where the old behavior is restored

But then, if the rust-toolchain.toml mentions only the cargo component does it mean that CI will still implicitly install clippy/rustfmt as it did before? That would be rather unintuitive. Do we need to make any change in setup-rust-toolchain action specifically to prevent that?

I understand that may grant a major breaking version for this GitHub action, but maybe it's worth it? Could be a patch release though as it would break CI code that was relying on implicit undocumented behaviors

[rami3l]

@Veetaha Sorry for the confusion. I did a throughout review of what happened and decided to stick to the new behavior. I have updated the comment accordingly. 🙇

[Veetaha]

@rami3l I see, I'm all for fixing the old implicit behavior. I hope there aren't too many people who mistakenly relied on it. It took me some time to figure out what was happening but anyway the fix was simple enough.

[jonasbb]

Given the overall feedback to this, the rustup change seems not to be a big issue. I was initially considering if the action should force enable the rustup default profile to restore the previous behavior.

I am considering just leaving everything as is and just suggesting to update the rust-toolchain.toml files to either include all the desired components or to include the desired profile:

[toolchain]
# other configurations
components = [ "clippy", "rustfmt" ]
profile = "default"

[kpfleming]

This problem just happened in an internal repo today; every run through yesterday installed rustfmt even without a profile specified in rust-toolchain.toml, but today's run did not.