`master` contains a single failing test
drahnr opened this issue · comments
rev a70346110554f9f37601b9dcc1e19a3e71ede889
fails consistently for me with one test case:
RUST_BACKTRACE=1 cargo t --test sccache_cargo
Finished test [unoptimized + debuginfo] target(s) in 1.01s
Running target/debug/deps/sccache_cargo-8d71709abea60091
running 1 test
test test_rust_cargo ... FAILED
failures:
---- test_rust_cargo stdout ----
thread 'test_rust_cargo' panicked at 'Unexpected failure.
code-2
stderr=\`\`\`sccache: error: Server startup failed: Address in use
\`\`\`
command=`"/media/supersonic1t/projects/sccache/target/debug/sccache" "--start-server"`
code=2
stdout=\`\`\`sccache: Starting the server...
\`\`\`
stderr=\`\`\`sccache: error: Server startup failed: Address in use
\`\`\`
', /home/bernhard/.cargo/registry/src/github.com-1ecc6299db9ec823/assert_cmd-1.0.2/src/assert.rs:158:13
stack backtrace:
0: rust_begin_unwind
at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/std/src/panicking.rs:493:5
1: std::panicking::begin_panic_fmt
at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/std/src/panicking.rs:435:5
2: assert_cmd::assert::Assert::success
at /home/bernhard/.cargo/registry/src/github.com-1ecc6299db9ec823/assert_cmd-1.0.2/src/assert.rs:158:13
3: sccache_cargo::test_rust_cargo_cmd
at ./tests/sccache_cargo.rs:79:5
4: sccache_cargo::test_rust_cargo
at ./tests/sccache_cargo.rs:17:5
5: sccache_cargo::test_rust_cargo::{{closure}}
at ./tests/sccache_cargo.rs:16:1
6: core::ops::function::FnOnce::call_once
at /home/bernhard/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/ops/function.rs:227:5
7: core::ops::function::FnOnce::call_once
at /rustc/2fd73fabe469357a12c2c974c140f67e7cdd76d0/library/core/src/ops/function.rs:227:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
failures:
test_rust_cargo
test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 4.53s
error: test failed, to rerun pass '--test sccache_cargo'
Unfortunately, I can't reproduce this locally (Ubuntu 20.10).
Can you try running sccache --stop-server
? The test suite should do it automatically, but maybe this helps...
Which SCCACHE_*
env vars are present in your environment? Can you reproduce this using some older commits, e.g. before std::future::Future
migration PR was merged?
I think the reason here is, that the local sccache server running via systemd restarts itself and hence blocks the port. I am not sure if any of those tests make much sense without containerization to avoid false negatives like this.
To solve that, it would be good to assign a random new port for each test, no?