incremental test run

[davemilter]

May be I missed something, but I can non find any mention for this.
It would be nice to get from cargo list of crates that would be rebuilt
by cargo build, and then run tests only for affected crates in workspace.

[sunshowers]

Thanks for the request! Hmmm, this is a really interesting idea. So basically examine the set of test binaries that were rebuilt, and run tests for just those binaries.

I've been thinking about this for a little while and I have some concerns about this. The main one is that if a test run is cancelled due to a failing test, or you Ctrl-C in the middle of a test run, rerunning the previous command will result in no tests being run. This feels like it severely breaks user expectations in a way that makes me really uncomfortable.

I've implemented a more complex version of the idea that compares the source code across two revisions -- this has the advantage of not requiring the previous version of the source built (and so being better for CI), and also avoiding the main pitfall above. I'd like to spend some time adding this to nextest soon.

I think if we do decide to implement this, it would be a good fit for filter expressions as a rebuilt() operator.

[davemilter]

I thought about calling touch file for all files mentioned in git diff to force cargo to rebuild,
because of in our case cargo build time is much less than cargo test.

But if there is determinator then it is much simple to get information from it in compare to forcing rebuild.

Thanks for mention and creation of determinator.

[sunshowers]

@davemilter so your plan was to run cargo build && touch <changed files> && cargo nextest run -E 'rebuilt()'? Interesting, definitely see the use case for that.

[alecmocatta]

Related issue I posted to the cargo repo rust-lang/cargo#10673

[gtrak]

ocaml/dune does this ocaml/dune#4390 (comment)