New env RUSTUP_AUTO_SELF_UPDATE to configure rustup self update

[tesuji]

Problem you are trying to solve

cc #3709
In the past, every time a new rustup version is released, github actions takes about 2 weeks to update
rustup binary to new versions. In that meantime, the users have to pass --no-self-update directly to
avoid unsuccessfully updating.

Solution you'd like

I would like rustup to add an environment variable NO_SELF_UPDATE that once set, it behaves the same as passing --no-self-update flag to rustup binary.

The NO_SELF_UPDATE env will be globally set in CI files for every build jobs. While --no-self-update flag has to be passed to every rustup install invocations.

Notes

No response

[rami3l]

@tesuji Hi! I remember the recommended mitigation would be running rustup set auto-self-update disable first (#3709 (comment))... So indeed there's no need to add --no-self-update all the time.

[tesuji]

Thanks for fast respond. I don't think running rustup set auto-self-update disable per CI jobs for each OSes/machines is that different from adding --no-self-update flag. Maybe I am using it the wrong way?

cc #3709 (comment)

The proposed env can be globally set only once for each CI file.
If rustup has a settings file that can be read per git repository (like .cargo/config), we could use that instead.

[rami3l]

Thanks for fast respond. I don't think running rustup set auto-self-update disable per CI jobs for each OSes/machines is that different from adding --no-self-update flag. Maybe I am using it the wrong way?

@tesuji Hmmm so far the issue seems to be Windows-only. Do you have dozens of different Windows workflows to configure?

Don't get me wrong, this is a legit feature request and I don't see a reason why we can't add such a config option. However it definitely cannot be shipped very soon, so I wonder how to solve your immediate problem first without causing too much hassle.

[tesuji]

Thank you for your sympathy. I agree that the proposed env cannot shipped anytime soon. However, the problem could occur again in the future whenever a new rustup is released. So I think the proposed environment variable could be useful for the future. In the meantime, I'm passing --no-self-update directly for each rustup install command.

Do you have dozens of different Windows workflows to configure?

My CI Windows workflows include:

• a build job for 4 targets: x86_64-pc-windows-msvc, i686-pc-windows-msvc, x86_64-pc-windows-gnu, i686-pc-windows-gnu
• a clippy check.
• a doc build (cargo doc) that uploads the result to gh-pages
• an optional rudra or mirai build for checking unsafe code.

[djc]

I think it might be interesting to consider if rustup can detect via some environment variable that it is running in well-known CI environments, and disable the self update check in that case?

[ChrisDenton]

Rustup could default to not auto update if the CI environment variable is present. This is simple both to implement and explain to users.

[tesuji]

I like that. Though I was worry that checking CI env is opt-out, while an new env var is opt-in

[ChrisDenton]

Personally I think disabling auto-update in CI is almost always the right option so it makes sense for it to be the default there.

[rami3l]

Rustup could default to not auto update if the CI environment variable is present. This is simple both to implement and explain to users.

@ChrisDenton While I like that proposal... will that interfere with other auto-update settings, and possibly with our own CI?

[ChrisDenton]

I think any auto-update setting should override the CI check. It would just be a default.

In rustups's own CI there may need to be a separate test that unsets the "CI" environment variable when running rustup to check that auto-update is enabled in that case.

[djc]

I think most of our tests can use a fake environment anyway, so we can make sure it does not include CI?

Should we close this issue in favor of #3824? I'm not sure it makes sense to keep both going (I'd probably have updated the title on this one instead of starting a fresh one.)

[rami3l]

@djc Yeah I guess we can close this as not planned (in favor of #3824) although in the long run I with rustup to be more like cargo in that most config options can be controlled by env vars... but alas.