Including workspace binaries in archive

[Guiguiprim]

I have a use case that is maybe half a hack.

> cd $WORKSPACE
> cargo build   # Builds all binaries
> cargo test    # Some tests use some binaries

In more details:

• in my workspace I have some small crates that only contains some small helpers binaries used by my project tests (or when doing some manual testing).
• cargo build at the workspace level builds all those binaries
• cargo test works, as the binaries have already being built and can be found
• cargo test without cargo build before fails, as the binaries are missing

Currently cargo nextest archive does not include those binaries even if cargo build was called before. Is it possible to include in the archive all the binaries in the target folder ? I guess the exact list would be hard to get other than just listing the folder content...

As a workaround, I can:

• Not use the archive feature (which is a be sad)
• Add empty integration tests in the crates with the helpers binaries (at the cost of more build and link time) to force cargo test to build them

So the question is: Is it reasonable to try to add the binaries inside the archive, or is my use-case too sketchy (which I would understand) ?

[sunshowers]

Hi Guilhem! Hope you're doing well :)

Good question -- currently, nextest includes any non-test binaries which have corresponding integration tests in their crates. So if you can include an integration test at all, even one without any tests, that would be ideal.

However I think it makes sense to support this in some form, and I'm wondering whether we should have the ability in configuration to include additional files (or globs) in archives. Do you want to work on this?

(One thing which I've seen people do is run cargo build within tests, so it's not completely unreasonable tbh.)

[Guiguiprim]

Hi, I'm fine thank you.

I need to see if I can manage to dedicate some time to it.

In any case, what do you see by "in configuration" ?

In the nextest.toml file, a list of files, binaries/libraries name to include in the archive from the target folder ? With a warning or an error if not found ?

Or something else ?

[sunshowers]

Actually -- for now I think maybe pass it in as an extra argument to cargo nextest archive to keep things simple. Something like cargo nextest archive --extra-include target/debug/foo --extra-include 'target/debug/bar*'. (Do make sure all the files are under the target directory, and archive them as target/debug/foo etc.)

[josecelano]

Hi @Guiguiprim @sunshowers , I have the same problem.

I'm working on a project called Torrust Tracker. @da2ce7 was working on the Cantainerfile and he's using cargo nextest archive to pass the build application to the next docker stage.

I was trying to reproduce a minimal example of how to use cargo nextest for that purpose. I'm writing an article for our blog where I explain the dockerfile we are using. This is the PR:

torrust/torrust-website#95 (comment)

And this is the example I can't make it work:

https://github.com/torrust/containerizing-rust-apps-examples/tree/main/archiving-and-reusing-builds

I'm going to confirm it but I guess I have the same problem because I do not have any integration test.

I suppose this could be a common pattern, since we consider it a good practice to take the binary that passes the tests. We could get the binary from previous stages (where we build the app) but this way seems to be cleaner and safer because you are sure you are using the binary that passed the tests.

[sunshowers]

With #1340 that should hopefully go out tomorrow, I believe it should be possible to simply say that you want to include "release/my-binary". There are still a few things to do (see docs), but hopefully this MVP should be enough to get started.