How to cache `cargo nextest` dependencies?

[lcmgh]

Hi!

First of all thanks for that nice tooling! I'm utilizing cargo nextest (https://github.com/nextest-rs/nextest) to build and archive my test binaries as described in here: https://nexte.st/book/reusing-builds.html

To be precise I am executing the following command:

RUN cargo nextest archive --archive-file /build/target/release/test-archive.tar.zst --release

which results in

Step 20/34 : RUN cargo nextest archive --archive-file /build/target/release/test-archive.tar.zst --release
 ---> Running in 0e5cd01420ea
 Downloading crates ...
  Downloaded security-framework-sys v2.6.1
  Downloaded wasi v0.10.2+wasi-snapshot-preview1
  Downloaded wasm-bindgen-shared v0.2.81
  Downloaded winreg v0.10.1
  Downloaded hermit-abi v0.1.19
  Downloaded redox_syscall v0.2.13
  Downloaded redox_users v0.4.3
  Downloaded mach v0.3.2
  Downloaded schannel v0.1.20
  Downloaded security-framework v2.6.1
  Downloaded wasm-bindgen-futures v0.4.31
  Downloaded wasi v0.11.0+wasi-snapshot-preview1
  Downloaded valuable v0.1.0
  Downloaded gloo-timers v0.2.4
  Downloaded core-foundation v0.9.3
  Downloaded wepoll-ffi v0.1.2
  Downloaded core-foundation-sys v0.8.3
  Downloaded vcpkg v0.2.15
  Downloaded wasm-bindgen-macro-support v0.2.81
  Downloaded winapi-util v0.1.5
  Downloaded wasm-bindgen v0.2.81
  Downloaded js-sys v0.3.58
  Downloaded bumpalo v3.10.0
  Downloaded wasm-bindgen-backend v0.2.81
  Downloaded wasm-bindgen-macro v0.2.81
  Downloaded windows_x86_64_msvc v0.36.1
  Downloaded windows_aarch64_msvc v0.36.1
  Downloaded windows_i686_msvc v0.36.1
  Downloaded web-sys v0.3.58
  Downloaded windows_x86_64_gnu v0.36.1
  Downloaded windows_i686_gnu v0.36.1
  Downloaded winapi-i686-pc-windows-gnu v0.4.0
  Downloaded winapi-x86_64-pc-windows-gnu v0.4.0
  Downloaded windows-sys v0.36.1
   Compiling myservice v0.1.0 (/build)
    Finished release [optimized] target(s) in 26.41s

I am not sure how I can make cargo chef cache those dependencies as well?

Dockerfile

#####################################################
#################### BUILD LAYER ####################
#####################################################

FROM my-rust-builder:latest AS planner
WORKDIR app
COPY . .
RUN cargo chef prepare --recipe-path recipe.json

#####################################################
#################### BUILD LAYER ####################
#####################################################

FROM my-rust-builder:latest as builder
WORKDIR /build

COPY --from=planner /app/recipe.json recipe.json

# Build dependencies - this is the caching Docker layer!
RUN cargo chef cook --release --all-targets --recipe-path recipe.json

COPY . /build

# Test without integration tests
RUN cargo test --lib --release

# Build and archive test binaries
RUN cargo nextest archive --archive-file /build/target/release/test-archive.tar.zst --release

[LukeMathWalker]

I have no idea to be honest - this would require understanding what cargo nextest archive is doing under the hood.

[sunshowers]

Hi @LukeMathWalker -- cargo nextest archive runs cargo test --no-run with the specified arguments (in the above case --release), then puts test binaries + other support files into an archive. In theory it just it should work without any special support from you (since the build step is just a wrapper around cargo test --no-run) so I'm actually surprised this doesn't just work out of the box.

[lcmgh]

Hi @sunshowers . What I am wondering is where do these dependencies (such as windows_x86_64_gnu) come from? Are they required to build the test executable and archive? They are not part of my app's (test) dependencies. Therefore I assume cargo chef cannot be aware of it.

my-service % cargo tree | grep windows # empty response
my-service % 

[LukeMathWalker]

Thanks for jumping in @sunshowers!

If it's invoking cargo test under the hood, then I confirm that it should "just work". Just like previous test command in that Dockerfile 🤔

[sunshowers]

@lcmgh I'd recommend looking at your Cargo.lock. I'd also recommend running cargo test --no-run separately to see if the same happens.

[LukeMathWalker]

I'm going to close this - feel free to re-open if you new details emerge.