Skip to content

Windows build cannot override Rust toolchain using RUSTUP_TOOLCHAIN environmental variable #19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
azriel91 opened this issue Mar 12, 2020 · 1 comment
Labels
M: builds Build, test, and deployment maintenance.

Comments

@azriel91
Copy link
Owner

In GitLab by @azriel91 on Mar 11, 2018, 21:00

TL;DR: Environmental variables do not appear to be visible to commands run from the Windows shell. The shell itself can see them though.

Rustup allows you to set the RUSTUP_TOOLCHAIN environmental variable to override the Rust toolchain commands.

On Windows, it works when I run it on a windows cmd shell:

azrie@TIMBERWOLF d:\apps
$ rustc --version --verbose
rustc 1.24.1 (d3ae9a9e0 2018-02-27)
binary: rustc
commit-hash: d3ae9a9e08edf12de0ed82af57ba2a56c26496ea
commit-date: 2018-02-27
host: x86_64-pc-windows-msvc
release: 1.24.1
LLVM version: 4.0

azrie@TIMBERWOLF d:\apps
$ cargo --version --verbose
cargo 0.25.0 (96d8071da 2018-02-26)
release: 0.25.0
commit-hash: 96d8071da2800d871677d090c31b030d5b9682bc
commit-date: 2018-02-26

azrie@TIMBERWOLF d:\apps
$ set RUSTUP_TOOLCHAIN=nightly-x86_64-pc-windows-msvc

azrie@TIMBERWOLF d:\apps
$ rustc --version --verbose
rustc 1.25.0-nightly (bd98fe0c0 2018-02-06)
binary: rustc
commit-hash: bd98fe0c05601d8a318a709adc4263f3348ea8d4
commit-date: 2018-02-06
host: x86_64-pc-windows-msvc
release: 1.25.0-nightly
LLVM version: 4.0

azrie@TIMBERWOLF d:\apps
$ cargo --version --verbose
cargo 0.26.0-nightly (1d6dfea44 2018-01-26)
release: 0.26.0
commit-hash: 1d6dfea44f97199d5d5c177c7dadcde393eaff9a
commit-date: 2018-01-26

However, when run through Gitlab CI, it does not. The environmental variable is set, but rustc and cargo still show that the stable toolchain is used (the default on that box):

$ echo RUSTUP_TOOLCHAIN: %RUSTUP_TOOLCHAIN%
RUSTUP_TOOLCHAIN: nightly-x86_64-pc-windows-msvc
$ cargo --version -v
cargo 0.25.0 (96d8071da 2018-02-26)
release: 0.25.0
commit-hash: 96d8071da2800d871677d090c31b030d5b9682bc
commit-date: 2018-02-26
$ rustc --version -v
rustc 1.24.1 (d3ae9a9e0 2018-02-27)
binary: rustc
commit-hash: d3ae9a9e08edf12de0ed82af57ba2a56c26496ea
commit-date: 2018-02-27
host: x86_64-pc-windows-msvc
release: 1.24.1
LLVM version: 4.0

It works on Linux through Gitlab CI (this Runner also has a stable default toolchain):

$ echo RUSTUP_TOOLCHAIN: ${RUSTUP_TOOLCHAIN}
RUSTUP_TOOLCHAIN: nightly-x86_64-unknown-linux-gnu
$ cargo --version -v
cargo 0.26.0-nightly (1d6dfea44 2018-01-26)
release: 0.26.0
commit-hash: 1d6dfea44f97199d5d5c177c7dadcde393eaff9a
commit-date: 2018-01-26
$ rustc --version -v
rustc 1.26.0-nightly (2789b067d 2018-03-06)
binary: rustc
commit-hash: 2789b067da2ac921b86199bde21dd231ace1da39
commit-date: 2018-03-06
host: x86_64-unknown-linux-gnu
release: 1.26.0-nightly
LLVM version: 6.0

More evidence can be seen in this build, which shows that Rustup installs the nightly toolchain in one command through the Runner's configuration, but in the next commands, it uses cargo and rustc from the stable toolchains:

$ IF NOT [%RUST_TOOLCHAIN%] == [] rustup override set %RUST_TOOLCHAIN%
info: syncing channel updates for 'nightly-x86_64-pc-windows-msvc'
info: latest update on 2018-03-07, rust version 1.26.0-nightly (2789b067d 2018-03-06)
info: downloading component 'rustc'
info: downloading component 'rust-std'
info: downloading component 'cargo'
info: downloading component 'rust-docs'
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'cargo'
info: installing component 'rust-docs'
info: override toolchain for 'D:\apps\gitlab_runner\builds\8e0bf602\0\azriel91\amethyst_menu_experiment' set to 'nightly-x86_64-pc-windows-msvc'

  nightly-x86_64-pc-windows-msvc installed - rustc 1.26.0-nightly (2789b067d 2018-03-06)

$ cargo --version -v
cargo 0.25.0 (96d8071da 2018-02-26)
release: 0.25.0
commit-hash: 96d8071da2800d871677d090c31b030d5b9682bc
commit-date: 2018-02-26
$ rustc --version -v
rustc 1.24.1 (d3ae9a9e0 2018-02-27)
binary: rustc
commit-hash: d3ae9a9e08edf12de0ed82af57ba2a56c26496ea
commit-date: 2018-02-27
host: x86_64-pc-windows-msvc
release: 1.24.1
LLVM version: 4.0

From these symptoms, it appears that Rustup does not see the environmental variables set by Gitlab CI, even though the shell can see them as variables.

@azriel91 azriel91 added the M: builds Build, test, and deployment maintenance. label Mar 12, 2020
@azriel91
Copy link
Owner Author

In GitLab by @azriel91 on Mar 12, 2018, 08:01

Found the issue. The windows runner's environment configuration had stable Rust on its %PATH%. It should only have .cargo\\bin on its path, which will redirect to the correct rustc and cargo commands.

Github issue that helped me discover this: rustup.rs/issues/965

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
M: builds Build, test, and deployment maintenance.
Projects
None yet
Development

No branches or pull requests

1 participant