Skip to content

Add rust-lang CI environment check #102428

New issue

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

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

Already on GitHub? # to your account

Closed
wants to merge 1 commit into from

Conversation

awakecoding
Copy link

@awakecoding awakecoding commented Sep 28, 2022

The current Rust bootstrap build scripts detect CI environments to enforce specific build options in the official rust-lang CI environment. The only problem is that it doesn't really distinguish between the official rust-lang CI environment, and just running in any CI environment. For my own Rust distribution built in GitHub Actions, I had to manually unset the GITHUB_ACTIONS environment variable as a temporary workaround. This pull request adds a new CiEnv::is_rust_lang_ci() check meant to detect when the scripts are executed from the official rust-lang CI environment.

To avoid undefining the GITHUB_ACTIONS environment variable, I added a check for the RUST_LANG_CI environment: if it is defined, it will override the result from CiEnv::is_rust_lang_ci(), if it is not defined, CiEnv::is_rust_lang_ci() will return true if it detects a CI environment. This should be sufficient to force-disable rust-lang CI specific checks in third-party CI environments, without affecting the current default behavior.

@rustbot rustbot added the T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) label Sep 28, 2022
@rust-highfive
Copy link
Contributor

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @jyn514 (or someone else) soon.

Please see the contribution instructions for more information.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 28, 2022
@jyn514 jyn514 added A-testsuite Area: The testsuite used to check the correctness of rustc T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue. labels Sep 28, 2022
Copy link
Member

@jyn514 jyn514 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not complete, you'll want to change at least https://github.com/rust-lang/rust/blob/b97f117e34af40b68a3c82aa6e0ec280c049d178/src/bootstrap/config.rs#L1297 as well.

Having looked at the code, I worry this is less reliable than forcing people to unset GITHUB_ACTIONS in their own CI. We don't have a good way to distinguish forks of rust-lang/rust from projects that are building it unchanged.

cc @Mark-Simulacrum, would be interested to hear your thoughts.

@@ -193,7 +193,7 @@ pub(crate) fn is_ci_llvm_available(config: &crate::config::Config, asserts: bool
return false;
}

if crate::util::CiEnv::is_ci() {
if crate::util::CiEnv::is_rust_lang_ci() {
Copy link
Member

@jyn514 jyn514 Sep 28, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is correct for forks. Say that llvm_sha == head_sha. That means that LLVM was modified in this commit (even if it's being built from a fork). We don't have enough info here to know whether this is a fork of rust-lang/rust, or whether someone's just downloaded the git history in addition to building from source. To be cautious I think we should avoid trying to download LLVM and force a build from source; people can still unset GITHUB_ACTIONS if this behavior is wrong for them.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had indeed missed the check in src/bootstrap/config.rs which enforces stage 2 builds in CI environments, it was the most problematic one for me. As is_ci_llvm_available(), I don't mind leaving it untouched, but rather than undefine GITHUB_ACTIONS, I would prefer adding an environment variable that could force-disable rust-lang CI checks. If you do a search for "is_ci()" you'll find a bunch of other helper functions that check for a CI environment for things that are benign in nature, like colorized output, etc.

@rust-log-analyzer

This comment has been minimized.

@awakecoding awakecoding force-pushed the rust-lang-ci-check branch 2 times, most recently from ad36a05 to b0bea87 Compare September 28, 2022 19:21
@Mark-Simulacrum Mark-Simulacrum self-assigned this Sep 28, 2022
@jyn514 jyn514 removed their assignment Oct 1, 2022
@Mark-Simulacrum
Copy link
Member

I think in general probably every case where we do something different depending on GITHUB_ACTIONS being set isn't right (unless its for things like turning off color or so); we should rely on a src/ci/run.sh-set variable for that (or config.toml option).

So I'm in general in favor of the direction of this PR, but I would prefer that we go farther and entirely decouple from github actions-only environment variables in rustbuild itself (and if not possible, discuss that on a case by case basis).

@Mark-Simulacrum Mark-Simulacrum added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 1, 2022
@awakecoding
Copy link
Author

@Mark-Simulacrum if I understand what you're saying, is that you would rather require that an environment variable like RUST_LANG_CI be defined explicitly to enable specific "official" CI checks separately from detecting and enabling those checks by default in a CI environment based on environment variables like GITHUB_ACTIONS? Let me know what modifications you would like to have made, and I'll modify my pull request

@awakecoding
Copy link
Author

Of course, if you have a fairly good idea of how you would like to address this specific issue and would rather open a separate pull request with the changes, that is fine with me as well. It doesn't need to be fixed by this specific pull request, all I care about is not having to undefine GITHUB_ACTIONS to avoid triggering the official rust-lang CI checks, it's hackish and makes custom CI builds harder

@Mark-Simulacrum
Copy link
Member

Yes, that sounds right. I don't have a lot of bandwidth to hunt down each case we rely on the GitHub actions set environment variables to make the determination - I think hopefully it's not too hard for you to make a reasonable decision in most of those places and switch them to using something like RUST_LANG_CI. We can iterate from there.

@JohnCSimon
Copy link
Member

@awakecoding
ping from triage:
what is the status of this PR? Seems like it's sat idle for a month.

@bors
Copy link
Collaborator

bors commented Dec 31, 2022

☔ The latest upstream changes (presumably #105058) made this pull request unmergeable. Please resolve the merge conflicts.

@JohnCSimon
Copy link
Member

@awakecoding
Ping from triage: I'm closing this due to inactivity, Please reopen when you are ready to continue with this.
Note: if you do please open the PR BEFORE you push to it, else you won't be able to reopen - this is a quirk of github.
Thanks for your contribution.

@rustbot label: +S-inactive

@JohnCSimon JohnCSimon closed this Jan 1, 2023
@rustbot rustbot added the S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. label Jan 1, 2023
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-testsuite Area: The testsuite used to check the correctness of rustc S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-infra Relevant to the infrastructure team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants