Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
test(build-std): Isolate output test to avoid spurious
[BLOCKING]
m…
…essages from concurrent runs (#14943) ### What does this PR try to resolve? 47c2095 didn't really fix the flakiness. Spun off from <#14938> 2a54190 build-std tests use the users `CARGO_HOME` for downloading registry dependencies of the standard library. This reduces disk needs of the tests, speeds up the tests, and reduces the number of network requests that could fail. However, this means all of the tests access the same locks for the package cache. In one test, we assert on the output and a `[BLOCKING]` message can show up, depending on test execution time from concurrent test runs. We are going to hack around this by having the one test that asserts on test output to use the standard `cargo-test-support` `CARGO_HOME`, rather than the users `CARGO_HOME`. There will then only be one process accessing the lock and no `[BLOCKING]` messages. ### How should we test and review this PR? No more assertion errors like this: ``` ---- test_proc_macro stdout ---- running `/home/runner/work/cargo/cargo/target/debug/cargo fetch -Zbuild-std -Zpublic-dependency` running `/home/runner/work/cargo/cargo/target/debug/cargo test --lib -Zbuild-std -Zpublic-dependency` thread 'test_proc_macro' panicked at tests/build-std/main.rs:394:10: ---- expected: tests/build-std/main.rs:388:27 ++++ actual: stderr 1 + [BLOCKING] waiting for file lock on package cache error: test failed, to rerun pass `-p cargo --test build-std` 2 + [BLOCKING] waiting for file lock on package cache 1 3 | [COMPILING] foo v0.0.0 ([ROOT]/foo) 2 4 | [FINISHED] `test` profile [unoptimized + debuginfo] target(s) in [ELAPSED]s 3 5 | [RUNNING] unittests src/lib.rs (target/debug/deps/foo-[HASH]) ```
- Loading branch information