The first two tests are blocking for over 60 seconds in Travis (using assert_cmd) about assert_cmd HOT 4 CLOSED

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

• An API but like #34 there are complications with letting people customize the behavior
• A feature flag to opt-in.
• ... something else?

from assert_cmd.

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

from assert_cmd.

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:

• https://travis-ci.org/mesalock-linux/mesabox/jobs/411409632#L996
• https://travis-ci.org/mesalock-linux/mesabox/jobs/411409632#L1696

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

• https://travis-ci.org/mesalock-linux/mesabox/jobs/411409633#L1013
• https://travis-ci.org/mesalock-linux/mesabox/jobs/411409633#L1425

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.

from assert_cmd.

Closing in favor of #4

from assert_cmd.