Skip to content

The first two tests are blocking for over 60 seconds in Travis (using assert_cmd) #43

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
mssun opened this issue Aug 2, 2018 · 4 comments

Comments

@mssun
Copy link
Contributor

mssun commented Aug 2, 2018

As described mesalock-linux/mesabox#41. I don't know why the first tests are always blocking for over 60 seconds. However, after the blocking issue, all testcases can be run without any problem.

test gnu::arch::test_x86_64 ... test gnu::arch::test_x86_64 has been running for over 60 seconds
test gnu::base32::test_decode ... test gnu::base32::test_decode has been running for over 60 seconds

This only happens in Travis: https://travis-ci.org/mesalock-linux/mesabox/jobs/411140601#L1305

I cannot reproduce this issue in my machine. Don't know why.

@epage
Copy link
Contributor

epage commented Aug 2, 2018

You are having the opposite problem of me with #4.

Your tests build with --target but assert_cmd doesn't. Even if they are the same target, cargo will do a unique build for it, blocking your tests. I'm guessing its two tests because they are running in parallel and one is being blocked on the other having the file lock.

This is a tricky situation. Ideally, we'd always pass along --target but for the default case, it'll slow people's tests down.

Options

@epage
Copy link
Contributor

epage commented Aug 2, 2018

btw once this is confirmed to be the problem, I'd like to merge these notes into #4.

@mssun
Copy link
Contributor Author

mssun commented Aug 2, 2018

Yes, this is the problem. Testing with cargo test does not have this issue, but cargo test --target x86_64-unknown-linux-musl still has.

cargo test:

cargo test --target x86_64-unknown-linux-musl

This is a tricky situation. Ideally, we'd always pass along --target but for the default case, it'll slow people's tests down.

I'm not quite understand the tricky situation, and how it affects the cargo test --target x86_64-unknown-linux-musl case. Do you mean that no matter what target I pass to the cargo, assert_cmd will do a build for me (and without any target flag)?

Anyway, for the solution, I prefer to a esay/intuitive one like a feature flag to opt-in.

@epage
Copy link
Contributor

epage commented Aug 2, 2018

Closing in favor of #4

@epage epage closed this as completed Aug 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants