Tracking issue for reuse build options

[sunshowers]

cargo-nextest 0.9.10 introduces experimental support for reusing the build across machines and invocations. This issue tracks stabilizing this option:

• How does this interact with loading shared libraries error #82?
• Verify option names.
• Ensure that the "cargo present on destination" and "cargo not present on destination" scenarios both work well.
• Is the current path remapping support sufficient?

cc @Guiguiprim

[Guiguiprim]

So I discovered a current limitation that might need some work.

# build machine
> cargo nextest list --list-type binaries-only --message-format json > binaries.json
# target machine
> cargo-nextest nextest <all reuse build args> --workspace -p some_package -j1
> cargo-nextest nextest <all reuse build args> --workspace --exclude some_package

This doesn't work as expected during tests run, the tests are not filtered base on packages (as they were all built).

I guess package filtering is normally pass on to cargo test --no-run and doesn't need to be consider after that.
In the reuse build use case, we probably need to handle it during the tests filtering.

[sunshowers]

@Guiguiprim Good catch! I think we should do two things:

1. Make all the cargo options mutually exclusive with --binaries-metadata.
2. Add a way to do post-build filtering by package name. This is useful even in the regular case because of feature unification concerns.

I think 2 should probably use a DSL similar to the one in #101 (comment). I realize we're pushing a lot to DSLs, but I think it's important to achieve orthogonality rather than adding a mess of options.

[Guiguiprim]

1. Should be easy to do. I might push a PR for it.
2. Sound good and a small challenge to do.

Otherwise this was successfully integrated in CI !

[sunshowers]

That's awesome, thanks for the news and also continuing to work on this!

re 1 we can publish that before 2 (which is quite a bit harder).

BTW when you're ready to do 2 let's discuss the design in a separate PR. I'm imagining a -E, --expr-filter expression-based filter.

[Guiguiprim]

For readers:

• Improving conflicting arguments handling was fixed: Make CargoOptions conflict with ReuseBuildOpts #116
• filtering is being worked here: Add expression based test filtering #117

[sunshowers]

@Guiguiprim I think to support #82 we need to rename the --binaries-dir-remap to --target-dir-remap, and preserve the directory structure within target in the archive. I'll recommend just archiving all of target for now, and we can add commands to create and extract a more specific archive later.

[sunshowers]

Doing the above in #120.

[sunshowers]

cargo-nextest 0.9.12 switches to --target-dir-remap (docs).

[sunshowers]

Pretty happy with this -- I think the only thing that's left is to write integration tests for the two cases, cargo-at-destination and cargo-not-present-at-destination. This can likely be done by uploading artifacts to the job:

• the cargo-nextest binary
• the target directory

then downloading them in a dependent job.

[sunshowers]

This is now ready as cargo-nextest 0.9.13, with:

• docs at https://nexte.st/book/reusing-builds.html
• example at https://github.com/nextest-rs/reuse-build-partition-example.