-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Disable rmake test inaccessible-temp-dir
on riscv64
#126917
Disable rmake test inaccessible-temp-dir
on riscv64
#126917
Conversation
This PR modifies cc @jieyouxu |
inaccessible-temp-dir
on riscv64
@Hoverbear does the test suite fail in CI if we run them as non-root? |
I'm glad you asked! I'm gonna find out. :) |
I did some investigation and here are some of the issues that pop up. Commenting out this is fine:
(You may need to remove the After that this line trips up with a permission error, that's relatively trivial to solve by making it rust/src/tools/remote-test-client/src/main.rs Line 109 in 9b88232
Sadly the rust/src/tools/remote-test-client/src/main.rs Lines 161 to 164 in 9b88232
Using a different workdirectory (since it's called pwd.lock) does not help, setting I guess the solution would be to stop using rust/src/tools/remote-test-client/src/main.rs Lines 135 to 149 in 9b88232
|
....huh, weird. |
I realized I could temporarily hack around this by setting this to This results in further issues:
Originating from: rust/src/tools/remote-test-client/src/main.rs Line 172 in 9b88232
Suffice it to say, I don't think this is a trivial enablement and it may be more suitable for a future PR which impacts both the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I'm fine with ignoring this test for riscv64 for now. Could you convert the Reason into a FIXME? i.e. this is something we should eventually fix in the long term.
r=me once you add a @bors delegate+ |
✌️ @Hoverbear, you can now approve this pull request! If @jieyouxu told you to " |
@rustbot author |
☔ The latest upstream changes (presumably #127216) made this pull request unmergeable. Please resolve the merge conflicts. |
48e99b5
to
1d733f0
Compare
1d733f0
to
8c353cb
Compare
🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened. |
…ssible-temp-dir-resolution, r=jieyouxu Disable rmake test `inaccessible-temp-dir` on riscv64 In rust-lang#126279 the `inaccessible-temp-dir` test was moved to rmake, I followed up with a 'fix' derived from rust-lang#126355 in rust-lang#126707. That 'fix' was misguided and hiding the true issue of the linker being incorrect for `riscv64gc-unknown-linux-gnu` (addressed in rust-lang#126916). Unfortunately, even with the linker fixed, this test doesn't work. I asked myself why this appeared to work on other platforms and investigated why. Both the containers for `armhf-gnu` and `riscv64gc` run their tests as `root` and have `NO_CHANGE_USER` set: https://github.com/rust-lang/rust/blob/553a69030e5a086eb3841d020db8c9c463948c72/src/ci/docker/host-x86_64/disabled/riscv64gc-gnu/Dockerfile#L99 This means the tests are run as `root`. As `root`, it's perfectly normal and reasonable to violate permission checks this way: ```bash $ sudo mkdir scratch $ sudo chmod o-w scratch $ sudo mkdir scratch/backs $ ``` Because of this, this PR makes the test ignored on `riscv64gc` for now. As an alternative, I believe the best long-term strategy would be to not run the tests as `root` for this job. ## Testing > [!NOTE] > `riscv64gc-unknown-linux-gnu` is a [**Tier 2 with Host Tools** platform](https://doc.rust-lang.org/beta/rustc/platform-support.html), all tests may not necessarily pass! This change should only ignore `inaccessible-temp-dir` and not affect other tests. You can test out the job locally: ```sh mv src/ci/docker/host-x86_64/disabled/riscv64gc-gnu src/ci/docker/host-x86_64/riscv64gc-gnu DEPLOY=1 ./src/ci/docker/run.sh riscv64gc-gnu ```
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#126403 (Actually report normalization-based type errors correctly for alias-relate obligations in new solver) - rust-lang#126803 (Change `asm-comments` to `verbose-asm`, always emit user comments) - rust-lang#126917 (Disable rmake test `inaccessible-temp-dir` on riscv64) - rust-lang#127050 (Make mtime of reproducible tarballs dependent on git commit) - rust-lang#127145 (Add `as_lang_item` to `LanguageItems`, new trait solver) - rust-lang#127184 (More refactorings to rustc_interface) - rust-lang#127202 (Remove global error count checks from typeck) - rust-lang#127233 (Some parser cleanups) - rust-lang#127245 (Add a test for `generic_const_exprs`) r? `@ghost` `@rustbot` modify labels: rollup
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#126403 (Actually report normalization-based type errors correctly for alias-relate obligations in new solver) - rust-lang#126803 (Change `asm-comments` to `verbose-asm`, always emit user comments) - rust-lang#126917 (Disable rmake test `inaccessible-temp-dir` on riscv64) - rust-lang#127050 (Make mtime of reproducible tarballs dependent on git commit) - rust-lang#127145 (Add `as_lang_item` to `LanguageItems`, new trait solver) - rust-lang#127184 (More refactorings to rustc_interface) - rust-lang#127202 (Remove global error count checks from typeck) - rust-lang#127233 (Some parser cleanups) - rust-lang#127245 (Add a test for `generic_const_exprs`) r? `@ghost` `@rustbot` modify labels: rollup
Rollup of 8 pull requests Successful merges: - rust-lang#123588 (Stabilize `hint::assert_unchecked`) - rust-lang#126403 (Actually report normalization-based type errors correctly for alias-relate obligations in new solver) - rust-lang#126917 (Disable rmake test `inaccessible-temp-dir` on riscv64) - rust-lang#127115 (unreferenced-used-static: run test everywhere) - rust-lang#127204 (Stabilize atomic_bool_fetch_not) - rust-lang#127239 (remove unnecessary ignore-endian-big from stack-overflow-trait-infer …) - rust-lang#127245 (Add a test for `generic_const_exprs`) - rust-lang#127246 (Give remote-test-client a longer timeout) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#126917 - ferrocene:hoverbear/riscv64-inaccessible-temp-dir-resolution, r=jieyouxu Disable rmake test `inaccessible-temp-dir` on riscv64 In rust-lang#126279 the `inaccessible-temp-dir` test was moved to rmake, I followed up with a 'fix' derived from rust-lang#126355 in rust-lang#126707. That 'fix' was misguided and hiding the true issue of the linker being incorrect for `riscv64gc-unknown-linux-gnu` (addressed in rust-lang#126916). Unfortunately, even with the linker fixed, this test doesn't work. I asked myself why this appeared to work on other platforms and investigated why. Both the containers for `armhf-gnu` and `riscv64gc` run their tests as `root` and have `NO_CHANGE_USER` set: https://github.com/rust-lang/rust/blob/553a69030e5a086eb3841d020db8c9c463948c72/src/ci/docker/host-x86_64/disabled/riscv64gc-gnu/Dockerfile#L99 This means the tests are run as `root`. As `root`, it's perfectly normal and reasonable to violate permission checks this way: ```bash $ sudo mkdir scratch $ sudo chmod o-w scratch $ sudo mkdir scratch/backs $ ``` Because of this, this PR makes the test ignored on `riscv64gc` for now. As an alternative, I believe the best long-term strategy would be to not run the tests as `root` for this job. ## Testing > [!NOTE] > `riscv64gc-unknown-linux-gnu` is a [**Tier 2 with Host Tools** platform](https://doc.rust-lang.org/beta/rustc/platform-support.html), all tests may not necessarily pass! This change should only ignore `inaccessible-temp-dir` and not affect other tests. You can test out the job locally: ```sh mv src/ci/docker/host-x86_64/disabled/riscv64gc-gnu src/ci/docker/host-x86_64/riscv64gc-gnu DEPLOY=1 ./src/ci/docker/run.sh riscv64gc-gnu ```
…rustdoc-io-error, r=jieyouxu Disable rmake test rustdoc-io-error on riscv64gc-gnu In rust-lang#126917 we disabled `inaccessible-temp-dir` on `riscv64gc-gnu` because the container runs the build as `root` (just like the `armhf-gnu` builds). Tests creating an inaccessible test directory are not possible, since `root` can always touch those directories. https://github.com/rust-lang/rust/blob/553a69030e5a086eb3841d020db8c9c463948c72/src/ci/docker/host-x86_64/disabled/riscv64gc-gnu/Dockerfile#L99 This means the tests are run as `root`. As `root`, it's perfectly normal and reasonable to violate permission checks this way: ```bash $ sudo mkdir scratch $ sudo chmod o-w scratch $ sudo mkdir scratch/backs $ ``` Because of this, this PR makes the test ignored on `riscv64gc` (just like on `armhf-gnu`) for now. As an alternative, I believe the best long-term strategy would be to not run the tests as `root` for this job. Some preliminary exploration was done in rust-lang#126917 (comment), however that appears a larger lift. ## Testing > [!NOTE] > `riscv64gc-unknown-linux-gnu` is a [**Tier 2 with Host Tools** platform](https://doc.rust-lang.org/beta/rustc/platform-support.html), all tests may not necessarily pass! This change should only ignore `inaccessible-temp-dir` and not affect other tests. You can test out the job locally: ```sh DEPLOY=1 ./src/ci/docker/run.sh riscv64gc-gnu ``` r? `@jieyouxu`
Rollup merge of rust-lang#127280 - ferrocene:hoverbear/disable-rmake-rustdoc-io-error, r=jieyouxu Disable rmake test rustdoc-io-error on riscv64gc-gnu In rust-lang#126917 we disabled `inaccessible-temp-dir` on `riscv64gc-gnu` because the container runs the build as `root` (just like the `armhf-gnu` builds). Tests creating an inaccessible test directory are not possible, since `root` can always touch those directories. https://github.com/rust-lang/rust/blob/553a69030e5a086eb3841d020db8c9c463948c72/src/ci/docker/host-x86_64/disabled/riscv64gc-gnu/Dockerfile#L99 This means the tests are run as `root`. As `root`, it's perfectly normal and reasonable to violate permission checks this way: ```bash $ sudo mkdir scratch $ sudo chmod o-w scratch $ sudo mkdir scratch/backs $ ``` Because of this, this PR makes the test ignored on `riscv64gc` (just like on `armhf-gnu`) for now. As an alternative, I believe the best long-term strategy would be to not run the tests as `root` for this job. Some preliminary exploration was done in rust-lang#126917 (comment), however that appears a larger lift. ## Testing > [!NOTE] > `riscv64gc-unknown-linux-gnu` is a [**Tier 2 with Host Tools** platform](https://doc.rust-lang.org/beta/rustc/platform-support.html), all tests may not necessarily pass! This change should only ignore `inaccessible-temp-dir` and not affect other tests. You can test out the job locally: ```sh DEPLOY=1 ./src/ci/docker/run.sh riscv64gc-gnu ``` r? `@jieyouxu`
…-testing, r=<try> Enable `riscv64gc` testing Together with joshua.zivkovic@codethink.co.uk, we've been starting to explore improving the state of the `riscv64gc-unknown-linux-gnu` target. Additionally, I'm looking to add support for this platform in [Ferrocene](https://github.com/ferrocene/ferrocene) ([Related PR](ferrocene/ferrocene#618)). Recently several PRs have landed improving the state of this target: * rust-lang#125220 * rust-lang#125669 * rust-lang#126355 * rust-lang#126279 * rust-lang#126707 * rust-lang#126916 * rust-lang#126917 * rust-lang#127280 The result has been that `riscv64gc-unknown-linux-gnu` now *should* pass the same CI tests that `x86_64-unknown-linux-gnu` and `aarch64-unknown-linux-gnu` do. ## Testing > [!NOTE] > While `riscv64gc-unknown-linux-gnu` is a [**Tier 2 with Host Tools** platform](https://doc.rust-lang.org/beta/rustc/platform-support.html) (meaning all tests may not necessarily pass) we do need to see all of the tests passing here. Indeed, the point of this PR is to get `riscv64gc-unknown-linux-gnu` into automated testing so the tests can *remain* working. You can test out the job locally: ```sh DEPLOY=1 ./src/ci/docker/run.sh riscv64gc-gnu ``` `DEPLOY=1` helps reproduce the CI's environment and also avoids the chance of a `llvm-c/BitReader.h` error (detailed in rust-lang#85424 and rust-lang#56650). try-job: riscv64gc-gnu
…-testing, r=<try> Enable `riscv64gc-gnu` testing Together with joshua.zivkovic@codethink.co.uk, we've been starting to explore improving the state of the `riscv64gc-unknown-linux-gnu` target. Additionally, I'm looking to add support for this platform in [Ferrocene](https://github.com/ferrocene/ferrocene) ([Related PR](ferrocene/ferrocene#618)). Recently several PRs have landed improving the state of this target: * rust-lang#125220 * rust-lang#125669 * rust-lang#126355 * rust-lang#126279 * rust-lang#126707 * rust-lang#126916 * rust-lang#126917 * rust-lang#127280 * rust-lang#127967 The result has been that `riscv64gc-unknown-linux-gnu` now *should* pass the same CI tests that `x86_64-unknown-linux-gnu` and `aarch64-unknown-linux-gnu` do. ## Testing > [!NOTE] > While `riscv64gc-unknown-linux-gnu` is a [**Tier 2 with Host Tools** platform](https://doc.rust-lang.org/beta/rustc/platform-support.html) (meaning all tests may not necessarily pass) we do need to see all of the tests passing here. Indeed, the point of this PR is to get `riscv64gc-unknown-linux-gnu` into automated testing so the tests can *remain* working. You can test out the job locally: ```sh DEPLOY=1 ./src/ci/docker/run.sh riscv64gc-gnu ``` `DEPLOY=1` helps reproduce the CI's environment and also avoids the chance of a `llvm-c/BitReader.h` error (detailed in rust-lang#85424 and rust-lang#56650). try-job: riscv64gc-gnu
In #126279 the
inaccessible-temp-dir
test was moved to rmake, I followed up with a 'fix' derived from #126355 in #126707.That 'fix' was misguided and hiding the true issue of the linker being incorrect for
riscv64gc-unknown-linux-gnu
(addressed in #126916).Unfortunately, even with the linker fixed, this test doesn't work. I asked myself why this appeared to work on other platforms and investigated why. Both the containers for
armhf-gnu
andriscv64gc
run their tests asroot
and haveNO_CHANGE_USER
set:rust/src/ci/docker/host-x86_64/disabled/riscv64gc-gnu/Dockerfile
Line 99 in 553a690
This means the tests are run as
root
. Asroot
, it's perfectly normal and reasonable to violate permission checks this way:Because of this, this PR makes the test ignored on
riscv64gc
for now.As an alternative, I believe the best long-term strategy would be to not run the tests as
root
for this job.Testing
Note
riscv64gc-unknown-linux-gnu
is a Tier 2 with Host Tools platform, all tests may not necessarily pass! This change should only ignoreinaccessible-temp-dir
and not affect other tests.You can test out the job locally: