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

[ChrisDenton]

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.

[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 (e.g. github actions uses $GITHUB_ENV).

[ChrisDenton]

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).

[djc]

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

[ChrisDenton]

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

[rami3l]

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

[rami3l]

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?

[ChrisDenton]

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

[ChrisDenton]

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.

[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.

[rami3l]

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.