Rustup 1.28.2 uses a different default profile during automatic installation

[jonasbb]

Verification

• I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue+is%3Aopen%2Cclosed and found no duplicates.
• I am on the latest version of Rustup according to https://github.com/rust-lang/rustup/tags and am still able to reproduce my issue.

Problem

The behavior of rustup toolchain install on GitHub Actions started to change after the last runner image update (2025-05-12). It contains the newest rustup 1.28.2. It now uses the minimal profile instead of the default profile. This results in many components being no longer installed compared to rustup 1.28.1.

 info: syncing channel updates for '1.86.0-x86_64-pc-windows-msvc'
 info: latest update on 2025-04-03, rust version 1.86.0 (05f9846f8 2025-03-31)
 info: downloading component 'cargo'
-info: downloading component 'clippy'
-info: downloading component 'rust-docs'
 info: downloading component 'rust-std'
 info: downloading component 'rustc'
-info: downloading component 'rustfmt'
 info: installing component 'cargo'
-info: installing component 'clippy'
-info: installing component 'rust-docs'
 info: installing component 'rust-std'
 info: installing component 'rustc'
-info: installing component 'rustfmt'

I could find this PR mentioning the same issue. actions/runner-images#12214
It points out that the change stems from f439f48.

I do not find anything related to this change in the rustup Changelog. Since this results in a quite obvious behavior change (namely tools like clippy being no longer installed) this should have been called out.

Steps

1. Create a rust-toolchain.toml file with this content.

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

2. Run rustup show active-toolchain || rustup toolchain install in GitHub Actions and observe which components are being installed.

Possible Solution(s)

This is a behavior change that should have been called out in the changelog.

Notes

I was originally informed about this via this bug report: actions-rust-lang/setup-rust-toolchain#60
The only obvious change between the working CI run (https://github.com/elastio/bon/actions/runs/14971709746/job/42053977014) and the failed CI run (https://github.com/elastio/bon/actions/runs/14996090362/job/42130576522) was the different rustup version and that fewer components are installed.

Rustup version

rustup 1.28.2 (e4f3ad6f8 2025-04-28)

Installed toolchains

Not available, since the error occurred in a CI run.

OS version

Windows

[rami3l]

@jonasbb Thanks for filing this issue.

This is likely an unexpected breakage from my side, will investigate. My apologies!

In the meantime, as a workaround, you can probably set the RUSTUP_VERSION=1.28.1 environment variable to downgrade to the old version when installing or doing a self-update.

---

Update: After having another look at the linked actions/runner-images#12214, it looks like it was the v1.28.1 code that was suffering from quality issues of copy-pasting. Indeed, the documentation/testing could have been better in that aspect, I'll try to add it in a reasonable timeframe.

[erik-bershel]

Hey @rami3l!

I'd love to see your recommendations for installation and configuration given the latest changes and the community's need to update or reconfigure runners environment on the fly. 🙇

[djc]

I'd love to see your recommendations for installation and configuration given the latest changes and the community's need to update or reconfigure runners environment on the fly. 🙇

What is your use case? What are you trying to do and why are you commenting on this issue?

[erik-bershel]

Hey @djc!

I am part of the team that builds and maintains base images for GitHub and Microsoft hosted runners (Actions/ADO). 😃 Our use case is to provide the latest version of Rust tools as part of Ubuntu/macOS/Windows based images.

We got a PR here: actions/runner-images#12214

But I don't really want to accept it since rust-docs package in the default profile (unusable due to the concept of images, takes up space that other users will need, wastes time during indexing and security scanning), while with the minimum profile users seems to be unhappy in some cases.

[djc]

@erik-bershel thanks for the additional context! Personally I feel that the rustup change is reasonable here, and so is your rationale not to install the default profile in GitHub runners. Given the lack of traffic on both the upstream PR and this issue and since other common ways of installing toolchains (like the dtolnay/rust-toolchain Action) also require manually specifying these components, I would be inclined to leave the current situation as is -- maybe there is a changelog where you could add some extra guidance? We could also certainly add a note to the rustup changelog.

@rami3l @ChrisDenton what do you think?

[rami3l]

@erik-bershel Sorry if my comment above hasn't been clear enough. My current conclusion is the same as that of @djc: we should keep the behavior in v1.28.2, not that in v1.28.1.

[erik-bershel]

I would be inclined to leave the current situation as is -- maybe there is a changelog where you could add some extra guidance?

Good question. I'm not sure if the issue is worth mentioning in the company blog - it's a behavior change for a specific case, not a bug, and unfortunately there are no public tools applicable to the situation in the Runner Images project environment. Maybe add an annotation or wait for users to contact us so that the problem and description are saved for future cases. 🤔 Okay, we'll see. In general, I got an answer to my question - we will think once more about using the default profile and make a final decision in light of all the circumstances.

---

@erik-bershel Sorry if my comment above hasn't been clear enough. My current conclusion is the same as that of @djc: we should keep the behavior in v1.28.2, not that in v1.28.1.

No, no. Everything is just fine and reasonable. This is rather an inaccuracy on my part. I was just asking about your opinion as an area owner regarding our case and nothing more. 😄

---

Thank you guys! ❤

[jonasbb]

@erik-bershel thanks for the additional context! Personally I feel that the rustup change is reasonable here, and so is your rationale not to install the default profile in GitHub runners. Given the lack of traffic on both the upstream PR and this issue and since other common ways of installing toolchains (like the dtolnay/rust-toolchain Action) also require manually specifying these components, I would be inclined to leave the current situation as is -- maybe there is a changelog where you could add some extra guidance? We could also certainly add a note to the rustup changelog.

@rami3l @ChrisDenton what do you think?

While I generally like to be explicit in CI environments, and thus defaulting to a minimal profile in CI is generally good, I do not like how this got introduced.

The change is a seemingly unintended consequence of a PR with a different purpose, #4258. Changing what the default value of a missing profile key in the toml file is, also shouldn't be part of a patch version. It feels weird that the toolchain file will work differently in the CI environment and on a local machine.

[djc]

While I generally like to be explicit in CI environments, and thus defaulting to a minimal profile in CI is generally good, I do not like how this got introduced.

The change is a seemingly unintended consequence of a PR with a different purpose, #4258. Changing what the default value of a missing profile key in the toml file is, also shouldn't be part of a patch version. It feels weird that the toolchain file will work differently in the CI environment and on a local machine.

@jonasbb I absolutely agree that it's unfortunate that the commit wasn't more explicit about this (and that none of the reviewers caught this) and that it should have been more explicitly communicated. However, since this ship has sailed, I've focused my previous comments on the question of whether we should revert this or not. Also, we probably should retroactively add this to the release notes.