Provide a built-in way for rustup to adapt to a CI environment

Discussed at the rust all-hands, it was suggested that it'd be good if rustup had better support for CI scenarios so it's less necessary for people to rely on third parties to provide them. This issue is intended to explore the existing options and see what we can adopt into rustup itself and how we can do so.

The most current github actions for rustup are rust-toolchain and setup-rust-toolchain.

What the actions do

sets environment variables by default such as:
- CARGO_UNSTABLE_SPARSE_REGISTRY=true
- CARGO_REGISTRIES_CRATES_IO_PROTOCOL=sparse (or =git for older cargo)
- CARGO_INCREMENTAL=0
- CARGO_PROFILE_DEV_DEBUG=0
- RUST_BACKTRACE=short
- CARGO_TERM_COLOR=always
runs rustup toolchain install to install the current default toolchain
Uses --profile minimal and --no-self-update when installing specified toolchains
provides problem matchers for cargo and rustfmt issues

They can also provide caching but that is deemed out of scope for rustup.

I guess the first big question is, if we want to do this, how do we want to go about setting environment variables? We could set them whenever cargo is called (but only if they're not set in the environment). Or we could have a command that outputs them to stdout and let the user redirect that as needed (e.g. github actions uses $GITHUB_ENV).

Uses --profile minimal and --no-self-update when installing specified toolchains

We've already disabled self-update in CI for a long time now:

rustup/src/cli/self_update.rs

Lines 482 to 486 in 8e6dbd2

    
           if cfg.process.var("CI").is_ok() && cfg.process.var("RUSTUP_CI").is_err() { 
        
               // If we're in CI (but not rustup's own CI, which wants to test this stuff!), 
        
               // disable automatic self updates. 
        
               return Ok(Self::Disable); 
        
           }

So the only thing to do on this point would be to default to --profile minimal. Though that could technically break people (I'm unsure what the actual impact would be).

I would guess that's going to be fairly breaking.

Yeah. We could provide an opt-in command like rustup setup CI or something like that so we can make such breaking changes.

@djc

I would guess that's going to be fairly breaking.

@djc If we are talking about GitHub, then maybe we are not introducing any new breakages at all since they are not using our default config: #4337

rustup/CHANGELOG.md

Lines 337 to 340 in 8e6dbd2

    
           - The logic of fetching the active toolchain's profile has been adjusted in automatic installation. 
        
             Now, when the profile is not specified, the profile from `rustup override set profile` will be chosen 
        
             instead of the profile named `default`. This aligns with the behavior of `rustup toolchain install`. 
        
             [pr#4258]

AFAIK GitHub defaults to the minimal profile.

Also related to: #3078

@ChrisDenton

I guess the first big question is, if we want to do this, how do we want to go about setting environment variables? We could set them whenever cargo is called (but only if they're not set in the environment). Or we could have a command that outputs them to stdout and let the user redirect that as needed

@ChrisDenton I think if I remember correctly from the discussion then our hypothetical GitHub Actions integration will take care of the forge-specific configurations, so as far as rustup is concerned the second option seems more reasonable, given that the env vars you want to set is, I assume, universal to any forge?

Yes, there shouldn't be any GitHub specific environment variables we set.

The problem matchers may be specific to particular forges but I figured they're spiritually similar to completions. Maybe we just need a command to install them.

Ok so concretely we need at least:

A command that output environment variables for CI in .env format
A command that gives a path to the problem matcher(s) (probably only gha will be supported initially)

So should we have a new ci command? E.g. rustup ci env or rustup ci matchers github.

@ChrisDenton

Ok so concretely we need at least:

A command that output environment variables for CI in .env format

A command that gives a path to the problem matcher(s) (probably only gha will be supported initially)

So should we have a new ci command? E.g. rustup ci env or rustup ci matchers github.

@ChrisDenton Sounds good to me! If you're not sure of the final naming, we can always hide the subcommand in clap first: we already have a few hidden subcommands actually.

@rustbot

If you don't mind I'd love to claim this.

@rustbot claim

Feel free!

Why are the cargo parts in rustup?

They do not have to be and long term it'd be nice if they weren't. However, as far as I'm aware Cargo can only change future versions of Cargo whereas rustup can provide a more or less consistent configuration for older versions (as much as that is possible).

If the problem is ensuring the Cargo team has ownership of the Cargo bits then I think we can figure out a technical solution to that. E.g. a crate that lives in the Cargo repo or maybe even just a single configuration file we can mirror in the rustup repo.

Is the impact of prior releases enough to make this central to the design? From what I've seen, people are generally on stable except for MSRV verification jobs which are not usually in the critical path of performance or behavior.

CARGO_PROFILE_DEV_DEBUG=0

Perhaps line-tables-only instead to avoid regressing backtraces in test failures?

@epage

Is the impact of prior releases enough to make this central to the design?

@epage I don't think so; the previous offline discussion at the all hands merely discussed the possibility of making a part of the current setup actions native to rustup. It is just that when looking at the prior art it seems that the existing solutions all tinker with the default cargo config.

From my perspective I don't particularly care whether rustup or cargo is delivering the required config options, as long as they are delivered to most of our users.

If cargo is moving towards the same direction then I'd love to merge a simpler version without any cargo bits, at least for the first step.

That would just leave problem matchers for a ci subcommand, right?

How do we plan to verify them? I just removed them from typos because of that problem. What I need to do i change typos action to use sarif. I use a tool to use sarif for clippy and would be interested in that as an end-goal for cargo. I wonder if problem matchers are worth thee hassle but I am biased in that I've been using dtolnay's action which doesn't have them.

@epage

That would just leave problem matchers for a ci subcommand, right?

@epage Currently removing all things cargo and rustup¹ leaves me with:

RUST_BACKTRACE=short

... I think that probably deserves a separate discussion but the rustup ci env subcommand is just for this one line then it might not be worth it, indeed.

How do we plan to verify them?

That's a good question!

https://github.com/r7kamura/rust-problem-matchers doesn't have a test suite but I'm looking at something like what GitHub does in setup-go where you basically write a small interpreter and verify at least the regex declarations are correct.

As for rustup we could also add some rustup-specific stuff here such as RUSTUP_PERMIT_COPY_RENAME=1, but in the goal of minimizing this I can let CI=1 imply everything we need to override in rustup in CI environments. ↩

Navigation Menu

Repository navigation

Provide a built-in way for rustup to adapt to a CI environment #5011

What the actions do

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	if cfg.process.var("CI").is_ok() && cfg.process.var("RUSTUP_CI").is_err() {
	// If we're in CI (but not rustup's own CI, which wants to test this stuff!),
	// disable automatic self updates.
	return Ok(Self::Disable);
	}

	- The logic of fetching the active toolchain's profile has been adjusted in automatic installation.
	Now, when the profile is not specified, the profile from `rustup override set profile` will be chosen
	instead of the profile named `default`. This aligns with the behavior of `rustup toolchain install`.
	[pr#4258]

Provide a built-in way for rustup to adapt to a CI environment #5011

Description

What the actions do

Activity

ChrisDenton commented on Aug 11, 2026

ChrisDenton commented on Aug 11, 2026

djc commented on Aug 11, 2026

ChrisDenton commented on Aug 11, 2026

rami3l commented on Aug 11, 2026

rami3l commented on Aug 11, 2026

ChrisDenton commented on Aug 11, 2026

ChrisDenton commented on Aug 11, 2026

ChrisDenton commented on Aug 12, 2026

rami3l commented on Aug 12, 2026

rami3l commented on Aug 17, 2026

ChrisDenton commented on Aug 17, 2026

epage commented on Aug 25, 2026

ChrisDenton commented on Aug 25, 2026

ChrisDenton commented on Aug 25, 2026

epage commented on Aug 26, 2026

bjorn3 commented on Aug 26, 2026

rami3l commented on Aug 26, 2026

epage commented on Aug 26, 2026

rami3l commented on Aug 26, 2026

Footnotes

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions