lukemathwalker / cargo-chef Goto Github PK

(The repo this issue is based on is private. I will describe the issue first, then try to recreate in a public minimal repo for further clarity and reproducibility.)

I have a project directory with structure

Cargo.toml  # [virtual manifest](https://doc.rust-lang.org/cargo/reference/workspaces.html#virtual-manifest) cargo.toml
src
  - libA
  - libB
  - libC
  - serviceZ
  - serviceY
  - serviceX
  - ...
...

Each of the services has individual Cargo.toml files and its own Dockerfile.

I've tried adding cargo-chef to one of these services (currently, we are either not being cache friendly or using a cargo new approach), say, serviceZ. cargo-chef does excellently at caching external dependencies for the entire workspace, but because it skelefies libA, libB, and libC, it has to rebuild these local library dependencies for each change in serviceZ. (The actual repo is too large to individually specify what dependencies to copy over and doing so would lead to keeping dependencies between the project and the Cargo.toml file in sync.) These end up consuming most of the compilation time: using cargo chef can bring subsequent runs from 404s down to 270s, but using a cargo new approach brings subsequent runs down from 404s to 70s. I can also visually see that we are recompiling local dependencies when running cargo build in the cargo chef approach while only serviceZ is compiled in the cargo new approach.

This is related to #74 and #64 in that I want very fine control over what I skelefy.

A quick aside: the cargo new approach suffers from changes in serviceZ invalidating the entire COPY src src line, leading to discarding the dependency cache on source changes. The way I've gotten around it is to separate this process into several stages, similar to the approach in cargo chef, but instead of sharing the recipe.json file between stages, I'm sharing an entire directory that should be the same between runs:

FROM rust as assembler
WORKDIR /usr/app
COPY src src
RUN rm -rf src/serviceZ
RUN USER=root cargo new --bin ./src/serviceZ
COPY src/serviceZ/Cargo.toml src/serviceZ/
# because the above stage should be the same between changes to `serviceZ`, 
# we can cache copying it to other stages

FROM rust as cacher
WORKDIR /usr/app
COPY Cargo.lock Cargo.lock
COPY rust-patches rust-patches
COPY vendored vendored
COPY .cargo .cargo
COPY Cargo.toml Cargo.toml
COPY --from=assembler /usr/app/src ./src
RUN cargo build --offline -p serviceZ && rm target/debug/deps/serviceZ*

FROM rust as builder
# actually copies over contents of serviceZ and builds it using cached items in cacher stage
...

I'm trying to use cargo chef cook to pre-build all needed dependencies of the agora project. But IIUC it fails at doing that.

Here's a repo that reproduces the issue: https://github.com/soenkehahn/cargo-chef-bug

In there, you can execute ./run.sh to see the bug.

RUN cargo chef cook --release --recipe-path recipe.json will build a bunch of dependencies, but then RUN cargo build --release apparently has to builds (or re-build) not all, but some dependencies. Here's the output of RUN cargo build --release:

 ---> Running in 4863dc7eb80d
   Compiling syn v1.0.70
   Compiling libc v0.2.94
   Compiling num_cpus v1.13.0
   Compiling mio v0.7.11
   Compiling atty v0.2.14
   Compiling socket2 v0.4.0
   Compiling clap v2.33.3
   Compiling proc-macro-error v1.0.4
   Compiling futures-macro v0.3.14
   Compiling tokio-macros v1.1.0
   Compiling tracing-attributes v0.1.15
   Compiling pin-project-internal v1.0.7
   Compiling maud_macros v0.22.2
   Compiling structopt-derive v0.4.14
   Compiling rust-embed-impl v5.9.0
   Compiling snafu-derive v0.6.10
   Compiling futures-util v0.3.14
   Compiling tokio v1.5.0
   Compiling tracing v0.1.25
   Compiling maud v0.22.2
   Compiling pin-project v1.0.7
   Compiling rust-embed v5.9.0
   Compiling structopt v0.3.21
   Compiling snafu v0.6.10
   Compiling futures-executor v0.3.14
   Compiling futures v0.3.14
   Compiling tokio-util v0.6.6
   Compiling tower v0.4.6
   Compiling h2 v0.3.2
   Compiling hyper v0.14.7
   Compiling agora v0.0.1 (/root/agora)
    Finished release [optimized] target(s) in 1m 21s
Removing intermediate container 4863dc7eb80d

If I understand correctly, cargo chef cook should pre-build all needed dependencies, so that cargo build would only have to build agora itself. Am I misunderstanding how cargo-chef is supposed to work? Or am I doing something else wrong in my repo? Or is there something going on with agora that makes cargo-chef misbehave?

Sorry that this is not a minimal reproduction of the problem.

Related to #76, not only does the Cargo.toml file contain the version of the package, but so does Cargo.lock. This means that despite only a version change, the cache will still be invalidated.

Currently there's no processing on the Cargo.lock file like there is on Cargo.toml. I see two possibilities,

1. Make use of the fact that Cargo.lock should be generated automatically, assuming the formatting.

[[package]]
name = "cargo-chef"
version = "0.1.24-alpha.0"

We know the version from the previous Cargo.toml formatting stage and we know the package name, so we can do a simple string find and replace

2. Parse the toml, loop through the packages til we find the one with our package name, then mutate the version. Finally reconverting the value back into a string.

Option 2 is probably more correct

Hi there, thanks for this awesome crate, have been using it with success for months. However, since a couple of days my docker builds for atomic-server are failing:

#17 [cacher 5/5] RUN cargo chef cook --release --recipe-path recipe.json
#17 0.858 error: failed to select a version for the requirement `atomic_lib = "^0.25.6"`
#17 0.858 candidate versions found which didn't match: 0.0.1
#17 0.858 location searched: /app/lib
#17 0.858 required by package `atomic-server v0.0.1 (/app/server)`
#17 0.859 thread 'main' panicked at 'Exited with status code: 101', /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/cargo-chef-0.1.24/src/recipe.rs:142:27
#17 0.859 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
#17 ERROR: executor failed running [/bin/sh -c cargo chef cook --release --recipe-path recipe.json]: exit code: 101

If I'm understanding this correctly, cargo sees the candidate version as version 0.0.1, while the cargo.toml indicates 0.25.6.

I've tried cargo installing older versions of cargo-chef:

RUN cargo install cargo-chef --version 0.1.20

but these fail (tried 0.1.20, 0.1.22):

#12 88.10 error[E0308]: mismatched types
#12 88.10   --> /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/cargo-chef-0.1.20/src/main.rs:73:58
#12 88.10    |
#12 88.10 73 |     #[clap(long, use_delimiter = true, value_delimiter = ",")]
#12 88.10    |                                                          ^^^ expected `char`, found `&str`
#12 88.10 
#12 88.13 error: aborting due to previous error

Running cargo build --release --bin atomic-server works fine on my machine.

Any ideas on what I could try? Thanks again!

I have a couple of dockerfiles each of which builds for a different feature set. Currently I can't pass the --features or --no-default-features arguments to cargo chef cook. Would be nice to support these.

I am getting this error while running cargo chef prepare (v0.1.20)

cargo chef prepare
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /xxx/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-chef-0.1.20/src/skeleton.rs:65:34
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Same with RUST_TRACEBACK=full in case it might be useful

❯ RUST_BACKTRACE=full cargo chef prepare
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /xxx/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-chef-0.1.20/src/skeleton.rs:65:34
stack backtrace:
   0:     0x56110e922df0 - std::backtrace_rs::backtrace::libunwind::trace::hdcf4f90f85129e83
                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/../../backtrace/src/backtrace/libunwind.rs:90:5
   1:     0x56110e922df0 - std::backtrace_rs::backtrace::trace_unsynchronized::h2669e30cb82f6732
                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
   2:     0x56110e922df0 - std::sys_common::backtrace::_print_fmt::hfbda19e17f6db318
                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/sys_common/backtrace.rs:67:5
   3:     0x56110e922df0 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h1a8751bf59281272
                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/sys_common/backtrace.rs:46:22
   4:     0x56110e947b2f - core::fmt::write::h7aa6cd0067dca82a
                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/core/src/fmt/mod.rs:1094:17
   5:     0x56110e9202b5 - std::io::Write::write_fmt::hd7dd3a1df9b6befb
                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/io/mod.rs:1580:15
   6:     0x56110e9252eb - std::sys_common::backtrace::_print::h551e9ec8a9fa8106
                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/sys_common/backtrace.rs:49:5
   7:     0x56110e9252eb - std::sys_common::backtrace::print::ha4b1c5e95fa040b3
                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/sys_common/backtrace.rs:36:9
   8:     0x56110e9252eb - std::panicking::default_hook::{{closure}}::h0b34c9ab7fb9f857
                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/panicking.rs:208:50
   9:     0x56110e924dcd - std::panicking::default_hook::h3067e8318decd17a
                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/panicking.rs:225:9
  10:     0x56110e92589d - std::panicking::rust_panic_with_hook::h81b8facc50f34daa
                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/panicking.rs:591:17
  11:     0x56110e925467 - std::panicking::begin_panic_handler::{{closure}}::ha376ab85d95a000e
                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/panicking.rs:495:13
  12:     0x56110e9232ac - std::sys_common::backtrace::__rust_end_short_backtrace::h6795c8afdd1a77e6
                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/sys_common/backtrace.rs:141:18
  13:     0x56110e9253f9 - rust_begin_unwind
                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/panicking.rs:493:5
  14:     0x56110e71f3c1 - core::panicking::panic_fmt::hbe99dddd3092ba3c
                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/core/src/panicking.rs:92:14
  15:     0x56110e71f30d - core::panicking::panic::h3de4db67bd397eb3
                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/core/src/panicking.rs:50:5
  16:     0x56110e79b4e7 - alloc::slice::<impl [T]>::sort_by::{{closure}}::h1eaf62c53785bfe8
  17:     0x56110e79b043 - alloc::slice::merge_sort::h47bf0508bd034a31
  18:     0x56110e7940e9 - chef::skeleton::Skeleton::derive::h67669d6be7fd637a
  19:     0x56110e78db4a - chef::recipe::Recipe::prepare::h1adbe7b566307dcb
  20:     0x56110e72c199 - cargo_chef::_main::h37403fc3b1dda56b
  21:     0x56110e725f16 - std::sys_common::backtrace::__rust_begin_short_backtrace::haae999a68f470d69
  22:     0x56110e725f2d - std::rt::lang_start::{{closure}}::h874d072e7514dd96
  23:     0x56110e925c9a - core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once::h3b8c329143d7638a
                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/core/src/ops/function.rs:259:13
  24:     0x56110e925c9a - std::panicking::try::do_call::h4b72c261b4eefc1b
                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/panicking.rs:379:40
  25:     0x56110e925c9a - std::panicking::try::h703d31b7896cbd49
                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/panicking.rs:343:19
  26:     0x56110e925c9a - std::panic::catch_unwind::h37cad9b35388a915
                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/panic.rs:431:14
  27:     0x56110e925c9a - std::rt::lang_start_internal::hab5a8a909af4f90e
                               at /rustc/42816d61ead7e46d462df997958ccfd514f8c21c/library/std/src/rt.rs:51:25
  28:     0x56110e72db05 - main
  29:     0x7f90de175840 - __libc_start_main
  30:     0x56110e71fb59 - _start
  31:                0x0 - <unknown>

EDIT:

I realized that issue #27 is absolutely relevant here. I think its all just fine the way things are working and i guess i understand the reasons behind it – delete all the "code" and just fill the target folder with the compiled dependencies. The "real" code comes back later in the build stage. Silly me. I just tried it with a little project and it worked (just using the docker commands) and i wanted it to extend to a more complex one and in the middle of development "take a look" at what cargo-chef would do to see if there are some problems already i need to fix before going the full docker route.

And now that i think i know how this hole thing is working – i feel a little bit stupid. But i agree with the comments in the other issue that a warning would be helpful to make the people using it aware that a) you're not supposed to use it "locally" and b) it will delete and alter your files on purpose and maybe with an explanation why. I'll try to get my test project working without "test cooking" locally and use it like it is supposed to :P

---- original message

I think this is related to issue #4 but i have the additional problem that cargo chef cook is also breaking my project by altering the respective Cargo.toml files from each project under a workspace. I have prepared a test project for you to replicate https://github.com/pythoneer/docker_build_test

cargo make build runs fine
cargo chef prepare --recipe-path recipe.json looks like its doing OK (can't tell if the *.json is correct)
cargo chef cook --recipe-path recipe.json breaks the project and
cargo make build does not build the project anymore because the Cargo.toml files are just wrong now

I don't know if this is not supposed to work in the first place because i haven't found a hint in the README (maybe the section about Limitations and caveats but to be honest i don't really understand that 100%)

I hope this helps. If you need any more information i am glad to help.

(love your book 👍 )

Hi, thanks for this awesome project!

It seems that all images on docker hub have -alpha.0 suffix in their version part (e.g. 0.1.26-alpha.0-rust-latest, 0.1.25-alpha.0-rust-latest).
https://hub.docker.com/r/lukemathwalker/cargo-chef/tags

I think these are pre-release versions, but I can't find any version tagged without this suffix (e.g. 0.1.26-rust-latest, 0.1.25-rust-latest).
Is this expected behavior?

Hi!
I tried running cargo chef cook on Enseada, which is composed of several crates linked up into a server crate that contains the main module.

After running cook, all the lib.rs become completely empty, and the main.rs only contains the following:

fn main() {}

I really don't think this is the desired behaviour 😄

I was able to reproduce it with a fresh repo: https://github.com/MatteoJoliveau/cargo-chef-repro
The same apply to a repo without dependencies (e.g. a bare repo generated with cargo new <name>)

It also modifies the Cargo.toml which I really would like to keep the way I wrote it 😅

Hello,
I am currently reading the zero2prod book on rust. I can't seem to get past this error while building a docker image for the project as outlined in the book and it seems to be owing to cargo chef.

Error:

 => ERROR [builder 2/4] RUN cargo chef cook --release --recipe-path recipe.json                                                                                                                       55.3s
------
 > [builder 2/4] RUN cargo chef cook --release --recipe-path recipe.json:
#14 3.336     Updating crates.io index
#14 55.25 thread 'main' panicked at 'Process terminated by signal', /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/cargo-chef-0.1.21/src/recipe.rs:137:21
#14 55.25 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
------
executor failed running [/bin/sh -c cargo chef cook --release --recipe-path recipe.json]: exit code: 101

Here is what my .Dockerfile looks like:

FROM lukemathwalker/cargo-chef:latest-rust-1.53.0 as chef
WORKDIR /app
FROM chef as planner
COPY . .
# Compute a lock-like file for our project
RUN cargo chef prepare --recipe-path recipe.json

FROM chef as builder
COPY --from=planner /app/recipe.json recipe.json
# Build our project dependencies, not our application!
RUN cargo chef cook --release --recipe-path recipe.json
# Up to this point, if our dependency tree stays the same,
# all layers should be cached.
COPY . .
ENV SQLX_OFFLINE true
# Build our project
RUN cargo build --release --bin zero2prod
FROM debian:buster-slim AS runtime
WORKDIR /app
RUN apt-get update -y \
  && apt-get install -y --no-install-recommends openssl \
  # Clean up
  && apt-get autoremove -y \
  && apt-get clean -y \
  && rm -rf /var/lib/apt/lists/*
COPY --from=builder /app/target/release/zero2prod zero2prod
COPY configuration configuration
ENV APP_ENVIRONMENT production
ENTRYPOINT ["./zero2prod"]

I have tried checking the codebase but can't seem to understand why the said line causes the error since it's only trying to get the environment variables.

I need to use --target x86_64-unknown-linux-musl to get a static binary.

Howdy! I work in a medium-large workspace that includes patches to a couple of dependencies (can provide a minimal example if that would be helpful). When trying to use cargo chef cook, it doesn't seem like the patches are included or applied---I'm seeing compilation errors.

Would it be possible to add rust-patches support to cargo-chef?

Is this actually the expected behavior? From my point of view, changing the project version shouldn't affect the overall build of dependencies, but in this case, this information is included in the recipe.json file, and even if you don't change the dependency tree this triggers a full rebuild of dependencies since the cache has been invalidated due to the change.

STEP 9: RUN cargo chef cook --release --recipe-path recipe.json
    Updating crates.io index

This step takes several times longer to complete than all others.
How to speed it up?
May be use local crate.io mirror?

Hi, in my project I have .cargo/config.toml:

[target.x86_64-unknown-linux-gnu]
rustflags = ["-C", "target-cpu=haswell"]

I currently have to copy my cargo config into my Docker cacher stage, so I'm caching and building with the same flags. Otherwise I get no caching, and no indication as to why.

It would be great if cargo chef prepare could emulate how cargo finds and merges config files, and include a merged .cargo/confg.toml in recipe.json.

Thanks,

Simon

Hi,

I'm building a Docker image using Alpine. I'm taking the path of building from Alpine instead of cross-compiling. In order to statically link libraries, I believe I must add RUSTFLAGS='-C target-feature=-crt-static' to cargo build commands, otherwise the built app throws SIGSEGV. I noticed that doing so, packages are recompiled by cargo build, while before I added RUSTFLAGS it was using cached builds as expected.

Reproduction steps:

$ docker run -it --rm -v /some/project:/app rust:alpine
# cd /app
# apk add --no-cache musl-dev
# cargo install cargo-chef
# cargo chef prepare
# RUSTFLAGS='-C target-feature=-crt-static' cargo chef cook --release --target x86_64-unknown-linux-musl
# RUSTFLAGS='-C target-feature=-crt-static' cargo build --release --target x86_64-unknown-linux-musl

(Update: I know this must not be done this way because cargo chef will erase main.rs, but this does show the bug.)

In spite of cargo chef forwarding the environment variables, the last line recompiles all dependencies. Do you have any idea why?

Besides, I'm surprised you don't mention this flag in your Alpine section of the README. Don't you need it?

I have a monorepo with multiple binaries sharing a set of common custom libraries, structured as so:

binary_a/
  Cargo.toml
  src/
binary_b/
  Cargo.toml
  src/
lib/
  lib_a/
    Cargo.toml
    src/
  lib_b/
    Cargo.toml
    src/

Each library in lib has its own dependencies and not every binary needs every library. I'm rather unclear if this is actually the best way to do it (please correct me if so), but each binary is configured as a workspace with each library it needs as a member. I'd originally placed this workspace at the root level, but upon further reading that seems to be incorrect.

Each binary Cargo.toml looks somewhat like this:

[workspace]
members = [
  "../lib/lib_a"
]

[package]
name = "binary_a"

[dependencies]
serde = "~1"
lib_a = {path = "../lib/lib_a"}

cargo cook prepare seems to work with this structure, the output contents field looks largely like the above toml, notably containing these local dependencies as such:

[dependencies.lib_a]
path = "../lib/lib_a"
features = []
optional = false

When it comes to cargo chef cook though, it fails because the lib/ folder isn't present: error: failed to read /usr/src/app/lib/lib_a/Cargo.toml

What am I doing wrong here? It's important to note that I don't want to cache the lib/ folder. 99% of the code is in that folder, so I only want to cache external (i.e. non-lib/) dependencies.

It's probably more my workspace/crate setup that's at fault more than anything else, but happy to add further details as required.

Cheers

Hello,

Thank you for the great work..

I have an issue I am not sure how to debug to find what is the problem.

I have the following docker file:

FROM lukemathwalker/cargo-chef as planner
WORKDIR app
COPY . .
RUN cargo chef prepare --recipe-path recipe.json

FROM lukemathwalker/cargo-chef as cacher
WORKDIR app
COPY --from=planner /app/recipe.json recipe.json
RUN cargo chef cook --release --recipe-path recipe.json


FROM ekidd/rust-musl-builder:latest AS builder
COPY --chown=rust:rust . .
# Copy over the cached dependencies
COPY --chown=rust:rust --from=cacher /app/target target
COPY --chown=rust:rust --from=cacher /usr/local/cargo /home/rust/.cargo
# RUN cargo build --release --bin back-office

FROM alpine:latest as runtime
WORKDIR app
COPY --from=builder /home/rust/src/target/x86_64-unknown-linux-musl/release/back-office /usr/local/bin
EXPOSE 8585
ENTRYPOINT ["/usr/local/bin/back-office"]

Here, back-office is the name of my package in cargo.toml.

This kind of works ... in the sense that, once the first docker build occurs, if cargo.toml isn't changed, the dependencies aren't downloaded again (the updating crate index ... does not happen at all).

However, the dependencies are compiled at every docker build. I tried many things, because from my point of view what is possibly happening is that the cargo on ekidd/rust-musl-builder takes in consideration stuff on cargo_home but does not recognize stuff coming from targedt from the cacher.

Do you have any hint on how I can fix that so that it works just like if I was using the rust image as builder?

Thanks,
Marlon

Sorry for the evolving issue here. And thanks for the github-rubberduck... So it turns out that the target wasm32-unknown-unknonw is not installed by default. To do so, add the following to your Dockerfile:

RUN rustup target add wasm32-unknown-unknown

For a full example, see https://github.com/ineiti/rust-docker/tree/wasm32 - which also has an example of how to use rand with wasm32...

I had some permission problems:

Failed to execute command.                                
Failed to cook recipe.                                                                                               
                                                                                                                     
Caused by:                                                                                                           
    0: failed to create file `Cargo.lock`                                                                            
    1: Permission denied (os error 13)  

yet my && ... && chain kept going.

Thanks very much for this project. I'm trying to clean up my cp dummy.rs Dockerfiles using cargo-chef. Unfortunately I have a problem with my multi-project workspace. Given a directory with two projects, like:

one - Cargo.toml, src/main.rs
two - Cargo.toml, src/lib.rs

When I run cargo chef prepare it runs correctly, but cargo chef cook complains that it doesn't find the Cargo.toml file. What is the correct way to use cargo chef here? Should it be run in each subdirectory?

I'm not exactly sure if this is happening as a result of cargo chef, but it seems to be based on my investigations into our dive results.

If this sounds like something that isn't a dumb mistake on my part, I can work on making a repro.

Hi, it would be cool if you could provide a Docker image on Docker Hub with cargo-chef installed.

Its Dockerfile could be as simple as

FROM rust
RUN cargo install cargo-chef 

The README is right that the RUN cargo install cargo-chef step gets cached, but that only holds if you run it on the same machine every time. A lot of CIs run each job on a different (virtual) machine, with empty local Docker layer cache.

(it is possible to cache using remote images with --cache-from, --target, and manual pushes/pulls, but it's less convenient)

Thanks for a very helpful tool.

I have several workspaces in my project, but cargo chef doesn't handle them. The error manifests by showing unresolved imports during the cargo build section.

Here's what my docker logs show:

Plans / Prepares fine.
...
cargo build --release
# Strangely downloads more deps here, when it shouldn't
...
# Strangely compiles only my_app, when it should do the workspaces in the correct order.
#23 41.65    Compiling my_app v0.0.1 (/app) 
#23 51.11 error[E0432]: unresolved imports [all my workspaces that it should've compiled before]

If you need me to provide a few commands to replicate this, I can do so.

Hi, I'm trying to follow along your excellent upcoming book "Zero to Production", and decided to actually build smaller docker containers than you outlined in chapter 5.
You referenced rust-musl-builder, which I was aware of (and used) before.

It turns out, cargo-chef does not play well with rust-musl-builder.
TL;DR:

• cargo-chef + official rust image works
• rust-musl-builder without cargo-chef works
• Putting both together gives me "unresolved imports" at the build stage

I don't know whether the problem comes from cargo-chef or rust-musl-builder, so I decided to create issues in both projects.
The corresponding issue in rust-musl-builder is emk/rust-musl-builder#115
And for completeness, here is the copy&pasted content of that:

What did you try to do?

I have this repository: https://git.christophsarnowski.com/cs/zero2prod
I want to build a Docker image using this rust-musl-builder for static linking, and I have a multi-stage Dockerfile to take advantage of docker layer caching (using cargo-chef).
The dockerfile is this:
https://git.christophsarnowski.com/cs/zero2prod/src/commit/e8fd292295755e5ca037c6814f685c6692f6705c/Dockerfile-alpine

What happened?

The 'docker build --tag latest -f Dockerfile-alpine .' fails with the following error at the the 'builder' stage:

   Compiling zero2prod v0.1.0 (/home/rust/src/app)
error[E0432]: unresolved imports `zero2prod::configuration`, `zero2prod::startup`, `zero2prod::telemetry`
 --> src/main.rs:6:5
  |
6 |     configuration::get_configuration,
  |     ^^^^^^^^^^^^^ could not find `configuration` in `zero2prod`
7 |     startup::run,
  |     ^^^^^^^ could not find `startup` in `zero2prod`
8 |     telemetry::{get_subscriber, init_subscriber},
  |     ^^^^^^^^^ could not find `telemetry` in `zero2prod`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
error: could not compile `zero2prod`

The "missing imports" do actually exist in the source tree.
This happens locally and in a drone CI environment, and with an empty cache (all layers that should be cached did not exist before this failure. Repeated tries to build the image do use the cache, but fail at the same step with the same message.)

What did you hope to happen?

Successful build of the docker image.
In contrast, the other Dockerfile:
https://git.christophsarnowski.com/cs/zero2prod/src/commit/e8fd292295755e5ca037c6814f685c6692f6705c/Dockerfile-debian

with almost exactly the same commands, but based on the official rust image, succeeds in building the image,
as does a local build outside docker.

Does ./test-image work?

I cancelled it about 10 minutes in, it did not show any failures that far. I can report back with a full run.
Also more importantly, building the same application with rust-musl-builder in less stages without cargo-chef worked fine.
It is sufficient to remove the "planner" and "cacher" stages and the "COPY --from=cacher... " lines.

I have a somewhat complex project for which cargo-chef appears to generate the recipe.json nondeterministically, which is defeating the caching inside docker.

$ cargo chef prepare && md5sum recipe.json
e0f07068fa2eb5406d61e98da3b4df3c  recipe.json
$ cargo chef prepare && md5sum recipe.json
acb5c8b3660c3348a7bc804aa0f58c43  recipe.json
$ cargo chef prepare && md5sum recipe.json
e49e1af1de73aa32ff2f44ce25be9f30  recipe.json

The reason for this is that cargo-chef is implicitly using a hashmap inside the toml dependency. I believe the fix is to update the dep to:

toml = {version = "0.5.7", features = ["preserve_order"] }

# cargo chef cook --release --recipe-path recipe.json -- --workspace

error: Found argument '--workspace' which wasn't expected, or isn't valid in this context

If you tried to supply `--workspace` as a PATTERN use `-- --workspace`

USAGE:
    cargo chef cook [FLAGS] [OPTIONS]

For more information try --help

Same with pretty much everything, i.e. --features, --package, etc.
What to do if I want to pre-cache a specific CI job?

Hey! Cool tool.

It may be useful for prospective users to have a quick comparison in the readme against using a plain Dockerfile such as this one which seems to be another common solution to the lack of cargo --build-deps:

FROM clux/muslrust:latest as build-deps
WORKDIR /src

COPY ./Cargo.toml ./Cargo.lock ./
RUN mkdir -p src/ && echo "fn main() { }" > src/main.rs
RUN cargo build --release

FROM build-deps as build-release
COPY ./src ./src
RUN cargo build --release

FROM scratch as release
COPY --from=build-release /src/target/x86_64-unknown-linux-musl/release/server /server
CMD ["/server"]

While I understand the benefits, some pros and cons such as buildkit (and maybe a build time comparison) may be nice!

Hello!
I'm working on deploying my workspace app with Docker and cargo chef, but I'm getting a panic trying to build it. Not sure what would be useful for you to help me debug it, let me know if I can provide anything.

benwis@Diziet vidette_rust % docker build --tag vidette --file Dockerfile .

[+] Building 126.8s (16/22)                                                                                            
 => [internal] load build definition from Dockerfile                                                              0.0s
 => => transferring dockerfile: 1.23kB                                                                            0.0s
 => [internal] load .dockerignore                                                                                 0.0s
 => => transferring context: 2B                                                                                   0.0s
 => [internal] load metadata for docker.io/library/debian:buster-slim                                             1.6s
 => [internal] load metadata for docker.io/library/rust:1.53.0                                                    1.6s
 => [internal] load metadata for docker.io/lukemathwalker/cargo-chef:latest-rust-1.53.0                           1.6s
 => [planner 1/4] FROM docker.io/lukemathwalker/cargo-chef:latest-rust-1.53.0@sha256:112f5524c4fb257ce9190ed8e74  0.0s
 => [internal] load build context                                                                                 0.3s
 => => transferring context: 551.51kB                                                                             0.3s
 => [builder 1/6] FROM docker.io/library/rust:1.53.0@sha256:54b76dd38a95fae4cdd57ce9742cdee01f4cb1ac6b9184b7d2a6  0.0s
 => [runtime 1/4] FROM docker.io/library/debian:buster-slim@sha256:1b138699146ca36569f2f2098c8e22c56756b5776f766  0.0s
 => CACHED [runtime 2/4] WORKDIR /app                                                                             0.0s
 => CACHED [builder 2/6] WORKDIR /app                                                                             0.0s
 => CACHED [planner 2/4] WORKDIR /app                                                                             0.0s
 => [planner 3/4] COPY . .                                                                                        3.0s
 => [planner 4/4] RUN cargo chef prepare  --recipe-path recipe.json                                               0.8s
 => CACHED [cacher 3/4] COPY --from=planner /app/recipe.json recipe.json                                          0.0s
 => ERROR [cacher 4/4] RUN RUST_BACKTRACE=1 cargo chef cook --release --recipe-path recipe.json                 121.0s
------
 > [cacher 4/4] RUN RUST_BACKTRACE=1 cargo chef cook --release --recipe-path recipe.json:
#16 2.378     Updating crates.io index
#16 94.21     Updating git repository `https://github.com/async-graphql/async-graphql/`
#16 97.76     Updating git submodule `https://github.com/async-graphql/examples`
#16 98.67     Updating git repository `https://github.com/Keats/jsonwebtoken`
#16 99.71     Updating git repository `https://github.com/launchbadge/sqlx.git`
#16 104.9  Downloading crates ...
#16 106.6   Downloaded actix-utils v3.0.0
#16 106.7   Downloaded block-buffer v0.7.3
#16 106.7   Downloaded bigdecimal v0.2.0
#16 106.7   Downloaded anyhow v1.0.42
#16 106.7   Downloaded byte-tools v0.3.1
#16 106.8   Downloaded bytestring v1.0.0
#16 106.8   Downloaded const_fn v0.4.8
#16 106.8   Downloaded chrono v0.4.19
#16 106.9   Downloaded darling_macro v0.12.4
#16 106.9   Downloaded convert_case v0.4.0
#16 106.9   Downloaded crypto-mac v0.10.1
#16 106.9   Downloaded foreign-types-shared v0.1.1
#16 106.9   Downloaded futures-channel v0.3.16
#16 106.9   Downloaded futures-sink v0.3.16
#16 106.9   Downloaded http-body v0.4.3
#16 106.9   Downloaded ident_case v1.0.1
#16 107.0   Downloaded hyper-rustls v0.22.1
#16 107.0   Downloaded subtle v2.4.1
#16 107.0   Downloaded time v0.1.44
#16 107.0   Downloaded instant v0.1.10
#16 107.0   Downloaded tap v1.0.1
#16 107.0   Downloaded httparse v1.4.1
#16 107.0   Downloaded getrandom v0.2.3
#16 107.0   Downloaded log v0.4.14
#16 107.0   Downloaded miniz_oxide v0.4.4
#16 107.1   Downloaded hyper v0.14.11
#16 107.1   Downloaded fnv v1.0.7
#16 107.1   Downloaded h2 v0.3.3
#16 107.1   Downloaded standback v0.2.17
#16 107.2   Downloaded thiserror v1.0.26
#16 107.2   Downloaded crc32fast v1.2.1
#16 107.2   Downloaded foreign-types v0.3.2
#16 107.2   Downloaded url v2.2.2
#16 107.2   Downloaded lazy_static v1.4.0
#16 107.2   Downloaded jobserver v0.1.23
#16 107.2   Downloaded uuid v0.8.2
#16 107.3   Downloaded idna v0.2.3
#16 107.3   Downloaded time-macros-impl v0.1.2
#16 107.3   Downloaded time-macros v0.1.1
#16 107.3   Downloaded unicode-normalization v0.1.19
#16 107.3   Downloaded language-tags v0.3.2
#16 107.3   Downloaded futures-intrusive v0.4.0
#16 107.4   Downloaded hex v0.4.3
#16 107.4   Downloaded dotenv_codegen v0.15.0
#16 107.4   Downloaded dotenv_codegen_implementation v0.15.0
#16 107.4   Downloaded byteorder v1.4.3
#16 107.4   Downloaded bitflags v1.2.1
#16 107.4   Downloaded ahash v0.7.4
#16 107.4   Downloaded strum v0.21.0
#16 107.4   Downloaded remove_dir_all v0.5.3
#16 107.4   Downloaded reqwest v0.11.4
#16 107.5   Downloaded tinyvec_macros v0.1.0
#16 107.5   Downloaded strum_macros v0.21.1
#16 107.5   Downloaded regex v1.5.4
#16 107.5   Downloaded socket2 v0.4.1
#16 107.6   Downloaded spin v0.9.2
#16 107.6   Downloaded tokio-rustls v0.22.0
#16 107.6   Downloaded lexical-core v0.7.6
#16 107.6   Downloaded http v0.2.4
#16 107.7   Downloaded try-lock v0.2.3
#16 107.7   Downloaded rand v0.8.4
#16 107.7   Downloaded semver-parser v0.10.2
#16 107.7   Downloaded serde_derive v1.0.127
#16 107.7   Downloaded serde v0.8.23
#16 107.7   Downloaded semver v0.11.0
#16 107.7   Downloaded typenum v1.13.0
#16 107.7   Downloaded scopeguard v1.1.0
#16 107.8   Downloaded quote v1.0.9
#16 107.8   Downloaded serde_test v0.8.23
#16 107.8   Downloaded serde-aux v2.2.0
#16 107.8   Downloaded static_assertions v1.1.0
#16 107.8   Downloaded rust-ini v0.13.0
#16 107.8   Downloaded serde_urlencoded v0.7.0
#16 107.8   Downloaded signal-hook-registry v1.4.0
#16 107.8   Downloaded ryu v1.0.5
#16 107.8   Downloaded slab v0.4.4
#16 107.8   Downloaded sha2 v0.9.5
#16 107.8   Downloaded simple_asn1 v0.5.4
#16 107.8   Downloaded tokio-native-tls v0.3.0
#16 107.9   Downloaded spin v0.5.2
#16 107.9   Downloaded rustc_version v0.3.3
#16 107.9   Downloaded regex-syntax v0.6.25
#16 107.9   Downloaded toml v0.5.8
#16 107.9   Downloaded encoding_rs v0.8.28
#16 108.1   Downloaded tracing v0.1.26
#16 108.1   Downloaded twoway v0.2.2
#16 108.1   Downloaded tokio-stream v0.1.7
#16 108.2   Downloaded tokio-macros v1.3.0
#16 108.2   Downloaded serde_json v1.0.66
#16 108.2   Downloaded rustls v0.19.1
#16 108.2   Downloaded sha-1 v0.8.2
#16 108.2   Downloaded radium v0.5.3
#16 108.2   Downloaded serde v1.0.127
#16 108.2   Downloaded proc-macro2 v1.0.28
#16 108.3   Downloaded sct v0.6.1
#16 108.3   Downloaded pin-utils v0.1.0
#16 108.3   Downloaded proc-macro-crate v1.0.0
#16 108.3   Downloaded pin-project-lite v0.2.7
#16 108.3   Downloaded pin-project-internal v1.0.8
#16 108.3   Downloaded serde-hjson v0.9.1
#16 108.3   Downloaded pin-project v1.0.8
#16 108.3   Downloaded tracing-core v0.1.18
#16 108.3   Downloaded rand_chacha v0.3.1
#16 108.3   Downloaded proc-macro-nested v0.1.7
#16 108.4   Downloaded pest_meta v2.1.3
#16 108.4   Downloaded pest_generator v2.1.3
#16 108.4   Downloaded smallvec v1.6.1
#16 108.4   Downloaded indexmap v1.7.0
#16 108.4   Downloaded sha-1 v0.9.7
#16 108.4   Downloaded stringprep v0.1.2
#16 108.4   Downloaded rand_core v0.6.3
#16 108.4   Downloaded ppv-lite86 v0.2.10
#16 108.4   Downloaded pkg-config v0.3.19
#16 108.4   Downloaded actix_derive v0.6.0
#16 108.4   Downloaded actix-web-httpauth v0.6.0-beta.2
#16 108.4   Downloaded actix-web v4.0.0-beta.8
#16 108.5   Downloaded tokio-util v0.6.7
#16 108.5   Downloaded actix-web-actors v4.0.0-beta.6
#16 108.5   Downloaded crc v2.0.0
#16 108.5   Downloaded generic-array v0.14.4
#16 108.5   Downloaded actix-web-codegen v0.5.0-beta.3
#16 108.5   Downloaded futures-util v0.3.16
#16 108.6   Downloaded futures-io v0.3.16
#16 108.6   Downloaded funty v1.1.0
#16 108.6   Downloaded adler v1.0.2
#16 108.6   Downloaded futures-macro v0.3.16
#16 108.6   Downloaded generic-array v0.12.4
#16 108.6   Downloaded ucd-trie v0.1.3
#16 108.6   Downloaded tower-service v0.3.1
#16 108.6   Downloaded time v0.2.27
#16 108.6   Downloaded claim v0.5.0
#16 108.6   Downloaded crc-catalog v1.1.1
#16 108.6   Downloaded block-buffer v0.9.0
#16 108.6   Downloaded syn v1.0.74
#16 108.7   Downloaded dirs v3.0.2
#16 108.7   Downloaded num_cpus v1.13.0
#16 108.7   Downloaded hashbrown v0.11.2
#16 108.7   Downloaded futures-task v0.3.16
#16 108.7   Downloaded unicode-segmentation v1.8.0
#16 108.7   Downloaded unicode-xid v0.2.2
#16 108.7   Downloaded futures-core v0.3.16
#16 108.8   Downloaded fake-simd v0.1.2
#16 108.8   Downloaded crossbeam-channel v0.5.1
#16 108.8   Downloaded cpufeatures v0.1.5
#16 108.8   Downloaded futures v0.3.16
#16 108.8   Downloaded flate2 v1.0.20
#16 108.8   Downloaded darling_core v0.12.4
#16 108.8   Downloaded itoa v0.4.7
#16 108.8   Downloaded hyper-tls v0.5.0
#16 108.9   Downloaded futures-executor v0.3.16
#16 108.9   Downloaded httpdate v1.0.1
#16 108.9   Downloaded heck v0.3.3
#16 108.9   Downloaded dirs-sys v0.3.6
#16 108.9   Downloaded darling v0.12.4
#16 108.9   Downloaded tempfile v3.2.0
#16 108.9   Downloaded sqlformat v0.1.6
#16 108.9   Downloaded opaque-debug v0.3.0
#16 108.9   Downloaded strsim v0.10.0
#16 108.9   Downloaded maplit v1.0.2
#16 108.9   Downloaded hmac v0.10.1
#16 108.9   Downloaded hashlink v0.7.0
#16 108.9   Downloaded futures-timer v3.0.2
#16 108.9   Downloaded derive_more v0.99.16
#16 109.0   Downloaded unicode_categories v0.1.1
#16 109.0   Downloaded version_check v0.9.3
#16 109.0   Downloaded ring v0.16.20
#16 109.5   Downloaded webpki-roots v0.21.1
#16 109.5   Downloaded tinyvec v1.3.1
#16 109.6   Downloaded whoami v1.1.2
#16 109.6   Downloaded unicode-bidi v0.3.5
#16 109.6   Downloaded aho-corasick v0.7.18
#16 109.6   Downloaded actix-codec v0.4.0
#16 109.6   Downloaded autocfg v1.0.1
#16 109.6   Downloaded ipnet v2.3.1
#16 109.6   Downloaded want v0.3.0
#16 109.6   Downloaded wyz v0.2.0
#16 109.6   Downloaded yaml-rust v0.4.5
#16 109.6   Downloaded async-trait v0.1.51
#16 109.7   Downloaded untrusted v0.7.1
#16 109.7   Downloaded arrayvec v0.5.2
#16 109.7   Downloaded async-stream v0.3.2
#16 109.7   Downloaded unchecked-index v0.2.2
#16 109.7   Downloaded webpki v0.21.4
#16 109.7   Downloaded base64ct v1.0.0
#16 109.7   Downloaded argon2 v0.2.2
#16 109.7   Downloaded actix v0.12.0
#16 109.7   Downloaded Inflector v0.11.4
#16 109.7   Downloaded thiserror-impl v1.0.26
#16 109.8   Downloaded crossbeam-queue v0.3.2
#16 109.8   Downloaded cc v1.0.69
#16 109.8   Downloaded form_urlencoded v1.0.1
#16 109.8   Downloaded cookie v0.15.1
#16 109.8   Downloaded either v1.6.1
#16 109.8   Downloaded dotenv v0.15.0
#16 109.8   Downloaded digest v0.9.0
#16 109.8   Downloaded digest v0.8.1
#16 109.8   Downloaded crypto-mac v0.8.0
#16 109.8   Downloaded matches v0.1.8
#16 109.8   Downloaded async-stream-impl v0.3.2
#16 109.8   Downloaded crossbeam-utils v0.8.5
#16 109.8   Downloaded bytes v1.0.1
#16 109.8   Downloaded cfg-if v1.0.0
#16 109.8   Downloaded config v0.10.1
#16 109.9   Downloaded brotli-sys v0.3.2
#16 109.9   Downloaded bitvec v0.19.5
#16 109.9   Downloaded atoi v0.4.0
#16 109.9   Downloaded brotli2 v0.3.2
#16 110.0   Downloaded block-padding v0.1.5
#16 110.0   Downloaded blake2 v0.9.1
#16 110.0   Downloaded actix-router v0.2.7
#16 110.0   Downloaded actix-rt v2.2.0
#16 110.0   Downloaded actix-tls v3.0.0-beta.5
#16 110.0   Downloaded md-5 v0.9.1
#16 110.0   Downloaded mime v0.3.16
#16 110.0   Downloaded local-waker v0.1.1
#16 110.0   Downloaded linked-hash-map v0.5.4
#16 110.0   Downloaded local-channel v0.1.2
#16 110.0   Downloaded linked-hash-map v0.3.0
#16 110.0   Downloaded actix-server v2.0.0-beta.5
#16 110.0   Downloaded base64 v0.13.0
#16 110.0   Downloaded native-tls v0.2.8
#16 110.0   Downloaded lru v0.6.6
#16 110.1   Downloaded actix-service v2.0.0
#16 110.1   Downloaded nom v5.1.2
#16 110.1   Downloaded multer v2.0.1
#16 110.1   Downloaded openssl-probe v0.1.4
#16 110.1   Downloaded once_cell v1.8.0
#16 110.1   Downloaded opaque-debug v0.2.3
#16 110.2   Downloaded num-traits v0.1.43
#16 110.2   Downloaded memchr v2.4.0
#16 110.2   Downloaded pem v0.8.3
#16 110.2   Downloaded password-hash v0.2.2
#16 110.2   Downloaded num-traits v0.2.14
#16 110.2   Downloaded percent-encoding v2.1.0
#16 110.2   Downloaded paste v1.0.5
#16 110.2   Downloaded parking_lot_core v0.8.3
#16 110.2   Downloaded parking_lot v0.11.1
#16 110.3   Downloaded num-integer v0.1.44
#16 110.3   Downloaded num-bigint v0.4.0
#16 110.3   Downloaded nom v6.1.2
#16 110.3   Downloaded pest_derive v2.1.0
#16 110.3   Downloaded validator_types v0.14.0
#16 110.3   Downloaded openssl-sys v0.9.65
#16 110.3   Downloaded pest v2.1.3
#16 110.4   Downloaded mio v0.7.13
#16 110.4   Downloaded tokio v1.9.0
#16 110.5   Downloaded lock_api v0.4.4
#16 110.5   Downloaded zstd-safe v3.1.0+zstd.1.4.9
#16 110.5   Downloaded openssl v0.10.35
#16 110.6   Downloaded zstd v0.7.0+zstd.1.4.9
#16 110.6   Downloaded validator v0.14.0
#16 110.6   Downloaded proc-macro-hack v0.5.19
#16 110.6   Downloaded actix-macros v0.2.1
#16 110.6   Downloaded actix-http v3.0.0-beta.9
#16 110.6   Downloaded num-bigint v0.3.2
#16 110.7   Downloaded libc v0.2.99
#16 110.8   Downloaded zstd-sys v1.5.0+zstd.1.4.9
#16 111.7  Downloading crates ...
#16 111.9   Downloaded jsonpath_lib v0.3.0
#16 111.9  Downloading crates ...
#16 112.1   Downloaded wiremock v0.5.6
#16 112.5    Compiling libc v0.2.99
#16 112.5    Compiling autocfg v1.0.1
#16 112.5    Compiling proc-macro2 v1.0.28
#16 112.5    Compiling syn v1.0.74
#16 120.5 thread 'main' panicked at 'Process terminated by signal', /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/cargo-chef-0.1.21/src/recipe.rs:137:21
#16 120.6 stack backtrace:
#16 120.9    0: std::panicking::begin_panic
#16 120.9    1: chef::recipe::Recipe::cook
#16 120.9    2: cargo_chef::_main
#16 120.9 note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
------
executor failed running [/bin/sh -c RUST_BACKTRACE=1 cargo chef cook --release --recipe-path recipe.json]: exit code: 101

Cargo.toml for main crate

[package]
name = "vidette"
version = "0.1.0"
edition = "2018"

[lib]
path = "src/lib.rs"

[[bin]]
path = "src/main.rs"
name = "vidette"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
email = {path="../email"}
async-graphql = { git = "https://github.com/async-graphql/async-graphql/", branch="actix-web-v4-beta", features = ["uuid", "chrono", "dataloader"] }
slab = "0.4.2"
uuid = { version = "0.8", features = ["serde", "v4"] }
chrono = {version= "0.4", features=["serde"]}
serde_derive = "1.0"
bigdecimal = {version="0.2", features=["serde"]}
async-trait = "0.1.50"
strum = "0.21.0"
strum_macros = "0.21.1"
anyhow = "1.0"
argon2 = "0.2"
rand_core = { version = "0.6", features = ["std"] }
thiserror = "1.0"
jsonwebtoken = { git = "https://github.com/Keats/jsonwebtoken", branch = "next" }
regex = "1.5"
futures = "0.3"
actix-web = { version = "4.0.0-beta.8" }
dotenv = "0.15.0"
dotenv_codegen = "0.15.0"
time = { version = "0.2", features = ["serde"] }
http = "0.2"
futures-util = "0.3.15"
actix-web-httpauth = "0.6.0-beta.2"
async-graphql-actix-web = { git = "https://github.com/async-graphql/async-graphql/", branch="actix-web-v4-beta" }
config = { version = "0.10.1", features = ["yaml"] }
serde = { version = "1.0.126", features = ["derive"] }
serde_json = "1.0.64"
sqlx = { git = "https://github.com/launchbadge/sqlx.git", features = [ "runtime-actix-native-tls", "macros","bigdecimal", "postgres", "uuid", "json", "chrono", "migrate", "offline"] }
serde-aux = "2.2.0"

[dev-dependencies]
jsonpath_lib = "0.3.0"
wiremock = {version="0.5"}
uuid = { version = "0.8", features = ["serde", "v4"] }
reqwest = { version = "0.11", features = ["json", "rustls-tls"] }
tokio = { version = "1", features = ["full"] }

Cargo.toml for tests crate

[package]
name = "vidette_tests"
version = "0.1.0"
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
actix-rt = "2"
vidette = {path="../vidette"}

[dev-dependencies]
jsonpath_lib = "0.3.0"
wiremock = {version="0.5"}
uuid = { version = "0.8", features = ["serde", "v4"] }
tokio = { version = "1", features = ["full"] }
# sqlx = { version = "0.5", features = [ "runtime-actix-native-tls", "macros","bigdecimal", "postgres", "uuid", "json", "chrono", "migrate", "offline"] }
sqlx = { git = "https://github.com/launchbadge/sqlx.git", features = [ "runtime-actix-native-tls", "macros","bigdecimal", "postgres", "uuid", "json", "chrono", "migrate", "offline"] }

futures = "0.3"
serde = { version = "1.0.126", features = ["derive"] }
serde_json = "1.0.64"
actix-web = { version = "4.0.0-beta.8" }
anyhow = "1.0"
reqwest = { version = "0.11",features = ["json", "rustls-tls"] }

Thank you for any help you can provide!

I have follow the example for my rust project and it was working well. However, it end up build everything when I was changing a single file in my src directory. Does the first stage of the Dockerfile should be something like this

FROM lukemathwalker/cargo-chef as planner
WORKDIR app
COPY Cargo.tml Cargo.lock .
RUN cargo chef prepare  --recipe-path recipe.json

Then the layer will get invalidated only when those 2 files will be modified. Is there a reason for not doing this ?

Thanks

I know, I have a most complicated build that ever existed... :D

For complicated reasons, that I can't get into RN my project structure is more or less:

root
  client
  client-lib-x
  api
  server

The client and server are a different workspace. But they both include the api as path = "../api".

So I'm running cargo-chef inside both server and client, but then cargo chef cook gets totally confused, and says:

Caused by:
  Unable to update /app/app/api 
                                                                                                                     
Caused by:                                                                                                           
  failed to read `/app/app/api/Cargo.toml`  

Even though path ... should be ... Hmmm... /app/api/Cargo.toml . Seems like some path concatenation somewhere where wrong WRT ...

I have a few docker volumes directories that require different user permissions, within my git repo (these are in the .gitignore and .dockerignore obviously). But when running prepare, it exits because it can't read those directories, when it should just give a warning.

After reading 5x Faster Rust Docker Builds with cargo-chef. Indeed, it was faster. But still produce big image. So I decide to use scratch as base image.

cargo-chef combined with scratch is awesome.

ARG BASE_IMAGE=rust:1.52-slim-buster
ARG VCS_REVISION

FROM $BASE_IMAGE as planner
WORKDIR app
RUN cargo install cargo-chef --version 0.1.20
COPY . .
RUN cargo chef prepare  --recipe-path recipe.json

FROM $BASE_IMAGE as cacher
WORKDIR app
RUN cargo install cargo-chef --version 0.1.20
COPY --from=planner /app/recipe.json recipe.json
RUN cargo chef cook --release --recipe-path recipe.json

FROM $BASE_IMAGE as builder
WORKDIR app
COPY . .
# Copy over the cached dependencies
COPY --from=cacher /app/target target
COPY --from=cacher $CARGO_HOME $CARGO_HOME
# We need static linking for smaller image.
RUN rustup target add x86_64-unknown-linux-musl
ARG VCS_REVISION
# `cargo build` doesn't work in static linking, need `cargo install`
RUN VCS_REVISION=$VCS_REVISION cargo install --target x86_64-unknown-linux-musl --path .

FROM scratch
WORKDIR app
COPY --from=builder /usr/local/cargo/bin/awesomeapp .
CMD ["./awesomeapp"]

Size comparison, with these dependencies:

rocket = { git = "https://github.com/SergioBenitez/Rocket", rev = "3a7559e", default-features = false }
rocket_contrib = { git = "https://github.com/SergioBenitez/Rocket", rev = "3a7559e" }
serde = { version = "1.0", features = ["derive"] }

• scratch : 8.63MB
• rust:1.52-slim-buster: 629MB
• rust:1.52: 1.24GB

Hello, thanks for the great tool!

I'm trying to make it work in CI. And I can give a lot of feedback in future.

Tried with many images and repositories, manually for starters.

cargo-chef v0.1.6

root@e893dc1d44bf:/builds/cargo-contract# cargo chef prepare  --recipe-path recipe.json
Error: Failed to compute recipe

Caused by:
    0: No such file or directory (os error 2)
    1: No such file or directory (os error 2)

Stack backtrace:
   0: chef::skeleton::Skeleton::derive
   1: chef::recipe::Recipe::prepare
   2: cargo_chef::main
   3: std::sys_common::backtrace::__rust_begin_short_backtrace
   4: std::rt::lang_start::{{closure}}
   5: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/ef663a8a48ea6b98b43cbfaefd99316b36b16825/library/core/src/ops/function.rs:259
      std::panicking::try::do_call
             at /rustc/ef663a8a48ea6b98b43cbfaefd99316b36b16825/library/std/src/panicking.rs:381
      std::panicking::try
             at /rustc/ef663a8a48ea6b98b43cbfaefd99316b36b16825/library/std/src/panicking.rs:345
      std::panic::catch_unwind
             at /rustc/ef663a8a48ea6b98b43cbfaefd99316b36b16825/library/std/src/panic.rs:382
      std::rt::lang_start_internal
             at /rustc/ef663a8a48ea6b98b43cbfaefd99316b36b16825/library/std/src/rt.rs:51
   6: main
   7: __libc_start_main
   8: _start

docker run -it paritytech/contracts-ci-linux:4e476221-20201029

git clone https://github.com/paritytech/cargo-contract .
cargo install cargo-chef
cargo chef prepare  --recipe-path recipe.json

The similar stuff happened to the paritytech/ink-ci-linux:65ef4994-20201008 image with https://github.com/paritytech/ink repo
and paritytech/ci-linux:2773c6ea-20201028 with https://github.com/paritytech/substrate. Except the latter is on stable toolchain and didn't show the unwind in the error.

Tried both with docker and podman.

Hi,

I hit an issue where cargo chef cook --release ignores the disabling of default features for dependencies, making it impossible to build Rusoto with Rustls.

In a workspace with layout:

.
├── backend
│   ├── Cargo.toml
│   └── src
├── Cargo.lock
├── Cargo.toml
├── Dockerfile
├── frontend_yew
│   ├── Cargo.toml
│   ├── index.html
│   ├── main.js
│   ├── pkg
│   ├── README.md
│   └── src
├── LICENSE-APACHE
├── LICENSE-MIT
├── README.md

and the backend Cargo.toml:

[dependencies]
actix-web = "3.2.0"
tracing-actix-web = "0.2.1"
tracing = "0.1.21"
serde_derive = "1.0.117"
serde = "1.0.117"
base-62 = "0.1.1"
uuid = { version = "0.8.1", features = ["v4"] }
tracing-futures = "0.2.4"
anyhow = "1.0.34"
rusoto_core = { version = "0.45.0", default_features=false, features=["rustls"] }
rusoto_s3 = { version = "0.45.0", default_features=false, features=["rustls"] }
tokio = "0.2"
lazy_static = "1.4.0"
tracing-log = "0.1.1"
tracing-subscriber = "0.2.15"
tracing-bunyan-formatter = "0.1.6"
actix-cors = "0.5.1"

Running cargo chef prepare --recipe-path recipetest.json generates:

{
  "skeleton": {
    "manifests": [
      {
        "relative_path": "Cargo.toml",
        "contents": "[workspace]\nmembers = [\"backend\"]\n"
      },
      {
        "relative_path": "frontend_yew/Cargo.toml",
        "contents": "bench = []\nbin = []\nexample = []\ntest = []\n\n[dependencies]\nwasm-bindgen = \"0.2.68\"\n\n[dependencies.web-sys]\nfeatures = [\"FormData\"]\noptional = false\nversion = \"0.3.45\"\n\n[dependencies.yew]\nfeatures = [\"services\"]\noptional = false\nversion = \"0.17.4\"\n\n[lib]\nbench = true\ncrate-type = [\"cdylib\", \"rlib\"]\ndoc = true\ndoctest = true\nharness = true\nplugin = false\nproc-macro = false\nrequired-features = []\ntest = true\n\n[package]\nauthors = [\"James McMurray <[email protected]>\"]\nautobenches = true\nautobins = true\nautoexamples = true\nautotests = true\ncategories = []\nedition = \"2018\"\nkeywords = []\nname = \"frontend\"\npublish = true\nversion = \"0.1.0\"\n"
      },
      {
        "relative_path": "backend/Cargo.toml",
        "contents": "bench = []\nexample = []\ntest = []\n\n[[bin]]\nbench = true\ndoc = true\ndoctest = true\nedition = \"2018\"\nharness = true\nname = \"elposhigu\"\npath = \"src/main.rs\"\nplugin = false\nproc-macro = false\nrequired-features = []\ntest = true\n\n[dependencies]\nactix-cors = \"0.5.1\"\nactix-web = \"3.2.0\"\nanyhow = \"1.0.34\"\nbase-62 = \"0.1.1\"\nlazy_static = \"1.4.0\"\nserde = \"1.0.117\"\nserde_derive = \"1.0.117\"\ntokio = \"0.2\"\ntracing = \"0.1.21\"\ntracing-actix-web = \"0.2.1\"\ntracing-bunyan-formatter = \"0.1.6\"\ntracing-futures = \"0.2.4\"\ntracing-log = \"0.1.1\"\ntracing-subscriber = \"0.2.15\"\n\n[dependencies.rusoto_core]\nfeatures = [\"rustls\"]\noptional = false\nversion = \"0.45.0\"\n\n[dependencies.rusoto_s3]\nfeatures = [\"rustls\"]\noptional = false\nversion = \"0.45.0\"\n\n[dependencies.uuid]\nfeatures = [\"v4\"]\noptional = false\nversion = \"0.8.1\"\n\n[lib]\nbench = true\ncrate-type = [\"rlib\"]\ndoc = true\ndoctest = true\nedition = \"2018\"\nharness = true\nname = \"elposhigu\"\npath = \"src/lib.rs\"\nplugin = false\nproc-macro = false\nrequired-features = []\ntest = true\n\n[package]\nauthors = [\"James McMurray <[email protected]>\"]\nautobenches = true\nautobins = true\nautoexamples = true\nautotests = true\ncategories = []\ndescription = \"Minimal pastebin service written in Rust + Actix Web\"\nedition = \"2018\"\nhomepage = \"https://github.com/jamesmcm/elposhigu\"\nkeywords = []\nlicense = \"MIT/Apache-2.0\"\nname = \"elposhigu\"\npublish = true\nreadme = \"README.md\"\nrepository = \"https://github.com/jamesmcm/elposhigu\"\nversion = \"0.1.0\"\n"
      }
    ],
    "lock_file": "#..."
}

However, cargo chef cook generates a backend/Cargo.toml with no default_features entries:

[dependencies.rusoto_core]
features = ["rustls"]
optional = false
version = "0.45.0"

[dependencies.rusoto_s3]
features = ["rustls"]
optional = false
version = "0.45.0"

In this case, this causes the build to fail due to having both rustls (and native-tls still included):

error[E0252]: the name `tls` is defined multiple times
  --> /home/archie/.cargo/registry/src/github.com-1ecc6299db9ec823/rusoto_core-0.45.0/src/lib.rs:25:5
   |
23 | use hyper_rustls as tls;
   |     ------------------- previous import of the module `tls` here
24 | #[cfg(feature = "native-tls")]
25 | use hyper_tls as tls;
   |     ^^^^^^^^^^^^^^^^ `tls` reimported here
   |
   = note: `tls` must be defined only once in the type namespace of this module
help: you can use `as` to change the binding name of the import
   |
25 | use hyper_tls as other_tls;
   |     ^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0252`.
error: could not compile `rusoto_core`

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: build failed
thread 'main' panicked at 'Exited with status code: 101', /home/archie/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-chef-0.1.8/src/recipe.rs:88:27
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Even using --no-default-features for the backend package directly doesn't seem to help.

Is it possible to use crate-level default features?

Hi.

I would love to see cargo-chef had pre-compiled binary on the release page.
I tend to avoid invoking the cargo install command in CI workflow and downloading the pre-compiled binary directly.
Resulting in just ~14 minutes, compared to ~30 minutes.

So instead of cargo install trunk, I do:

      # install trunk
      wget -qO- https://github.com/thedodd/trunk/releases/download/v0.10.0/trunk-x86_64-unknown-linux-gnu.tar.gz | tar -xzf-
      chmod +x trunk
      cp trunk ~/.cargo/bin/
      trunk --version

I prefer this approach than using lukemathwalker/cargo-chef as the base image. So I have more fined grain control over the image.

difference is unmaintained

The author of the difference crate is unresponsive.

Maintained alternatives:

• dissimilar

• treediff

• diffus

See advisory page for additional details.

Hello,
I'm experimenting further after #11 and faced something new.
When in the virtual workspace, and need to build something specific:

root@ced6a778bc7f:/builds/bin/utils/subkey# cargo chef cook --release --recipe-path recipe.json
error: failed to parse manifest at `/builds/bin/utils/subkey/primitives/core/Cargo.toml`

Caused by:
  can't find `bench` bench, specify bench.path
thread 'main' panicked at 'Exited with status code: 101', src/recipe.rs:82:27
stack backtrace:
   0: rust_begin_unwind
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:475
   1: std::panicking::begin_panic_fmt
             at /rustc/18bf6b4f01a6feaf7259ba7cdae58031af1b7b39/library/std/src/panicking.rs:429
   2: chef::recipe::Recipe::cook
   3: cargo_chef::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

docker run -it paritytech/ci-linux:3ec7097e-20201113

cargo install --git https://github.com/NathanHowell/cargo-chef --branch with-manifest-fixes

git clone https://github.com/paritytech/substrate .
# variant 1
cd ./bin/utils/subkey
cargo chef prepare  --recipe-path recipe.json
cargo chef cook --release --recipe-path recipe.json

# variant 2
cargo chef prepare  --recipe-path recipe.json
cd ./bin/utils/subkey
cargo chef cook --release --recipe-path ../../../recipe.json

Hi, I realise the README says

cargo-chef has not yet been tested extensively with projects leveraging build files.

...this issue is an attempt to change that. :)

I have created a minimal example crate leveraging build.rs file: https://github.com/strohel/cargo-chef-build-rs

The build using cargo-chef fails with the following error:

Step 16/20 : RUN cargo build --release --bin cargo-chef-build-rs
 ---> Running in 53c5f9739b5f
   Compiling cargo-chef-build-rs v0.1.0 (/app)
error: couldn't read /app/target/release/build/cargo-chef-build-rs-087b5874e2eb29d7/out/built.rs: No such file or directory (os error 2)
 --> src/main.rs:1:1
  |
1 | include!(concat!(env!("OUT_DIR"), "/built.rs"));

i.e. the file that is generated by build.rs is not present. It is kinda strange, because at this point, cargo chef is no longer involved (beyond files generated by it being present in /target). Maybe that somehow fools cargo to think that build.rs was already run, while it actually wasn't?

I'll be happy to help to resolve this.

Hello,
I'm using CARGO_TARGET_DIR to share cache between compilations in CI.
And my plan is to leverage cargo-chef to pre-populate the cache before CI job runs.
I'm doing it via docker voulmes, see in repro.

   Compiling ink_lang v3.0.0-rc2 (/builds/crates/lang)
    Finished dev [unoptimized + debuginfo] target(s) in 25.36s
Error: Failed to cook recipe.

Caused by:
    0: IO error for operation on /builds/target/debug: No such file or directory (os error 2)
    1: No such file or directory (os error 2)

Stack backtrace:
   0: chef::skeleton::Skeleton::remove_compiled_dummy_libraries
   1: chef::recipe::Recipe::cook
   2: cargo_chef::main
   3: std::sys_common::backtrace::__rust_begin_short_backtrace
   4: std::rt::lang_start::{{closure}}
   5: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
             at /rustc/ffa2e7ae8fbf9badc035740db949b9dae271c29f/library/core/src/ops/function.rs:259
      std::panicking::try::do_call
             at /rustc/ffa2e7ae8fbf9badc035740db949b9dae271c29f/library/std/src/panicking.rs:381
      std::panicking::try
             at /rustc/ffa2e7ae8fbf9badc035740db949b9dae271c29f/library/std/src/panicking.rs:345
      std::panic::catch_unwind
             at /rustc/ffa2e7ae8fbf9badc035740db949b9dae271c29f/library/std/src/panic.rs:382
      std::rt::lang_start_internal
             at /rustc/ffa2e7ae8fbf9badc035740db949b9dae271c29f/library/std/src/rt.rs:51
   6: main
   7: __libc_start_main
   8: _start

docker run -it -v /home/parity/cache/chef/:/ci-cache docker.io/paritytech/ink-ci-linux:3ec7097e-20201113

export CARGO_TARGET_DIR=/ci-cache/target/  # <-- this one is the cause

cargo install --git https://github.com/NathanHowell/cargo-chef --branch with-manifest-fixes

git clone https://github.com/paritytech/ink .

cargo chef prepare  --recipe-path recipe.json
cargo chef cook --release --recipe-path recipe.json

Without CARGO_TARGET_DIR chef cooks normally.

I've sccache installed and use it actively.
Unfortunately, cargo-chef=v0.1.6 (and v0.1.5, didn't dig deeper) throws an error when trying to

cargo install cargo-chef

info: cleaning up downloads & tmp directories
 ~ cargo install cargo-chef                                                                                                                                                                                                  
    Updating crates.io index
  Downloaded cargo-chef v0.1.6
  Downloaded 1 crate (13.1 KB) in 1.09s
  Installing cargo-chef v0.1.6
error: failed to compile `cargo-chef v0.1.6`, intermediate artifacts can be found at `/tmp/cargo-installWWQz80`

Caused by:
  failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `sccache rustc - --crate-name ___ --print=file-names --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=cfg` (exit code: 2)
  --- stderr
  error: Connection to server timed out

Workaround:
unset RUSTC_WRAPPER solves the problem.

#33 747.5 thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', /root/.cargo/registry/src/github.com-1ecc6299db9ec823/cargo-chef-0.1.12/src/skeleton.rs:244:60
#33 747.5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
#33 ERROR: executor failed running [/bin/sh -c cargo chef cook --release --recipe-path recipe.json]: exit code: 101

The project itself is closed source. I think I can share specific relevant bits if you direct me.

Although the dependency of clap is specified as 3.0.0-beta.2, it turns out that when performing cargo install cargo-chef, cargo always pulls the newest version matching semvar, ignoring the beta part. So at this moment, cargo will pull 3.0.0-beta.4 version of clap to build cargo-chef.

Due to change in clap-rs/clap#2686

I will do a fork and submit a pr for this.

Link to minimal repo: https://github.com/prestontw/cargo-chef-vendored-repo

I've vendored the dependencies of a small Rocket app using cargo vendor. I've then updated .cargo/config.toml so that cargo build uses the local dependencies. Trying to run cargo chef errors with checksum changes (since cargo chef has replaced all of the lib.rs files in the dependencies with empty files?).

I'm thinking if we make cargo chef aware of .cargo/config.toml, we will know not to skelefy these vendored files.

Aside: using cargo-local-registry is fine since it stores dependencies in zipped files, so cargo chef doesn't skelefy them.

I have noticed that in a scenario where auto binaries (binaries located in src/bin, but with no listing in the manifest) are read in using complete_from_path, the order in which the binaries are placed into the resulting manifest structure is not consistent. As a result, the cargo chef prepare may generate a few different versions of the recipe file with each call, even if nothing has changed, simply because of this inconsistent ordering.

Note that if the binaries are in the manifest file, rather than being auto-generated, things appear to be okay. That is the current workaround that I am using.

I've opened #33, which provides a potential fix and test case, although I'll admit both are a bit rough. Also, it only fixes auto binaries, I'm sure the same problem might exist with other auto-discovered targets that I'm not as familiar with.

Hello, thanks for this crate. I'm using it for the Docker builds of my git-cliff project for a couple of months now. But recently I got an error in my CI workflow:

 Step 8/20 : RUN cargo chef cook --release --recipe-path recipe.json
 ---> Running in e89886c52ec8
    Updating crates.io index
error: failed to select a version for the requirement `git-cliff-core = "^0.2.5"`
candidate versions found which didn't match: 0.0.1
location searched: /app/git-cliff-core
required by package `git-cliff v0.0.1 (/app/git-cliff)`
thread 'main' panicked at 'Exited with status code: 101', /usr/local/cargo/registry/src/github.com-1ecc6299db9ec823/cargo-chef-0.1.30/src/recipe.rs:145:27
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
The command '/bin/sh -c cargo chef cook --release --recipe-path recipe.json' returned a non-zero code: 101

Dockerfile: https://github.com/orhun/git-cliff/blob/72cee9caa632498c55a7c5f1aac2657fbb445b90/Dockerfile

I have already seen #84 and although it seems like the same issue, I realized I can build it just fine with cargo-chef v0.1.23 so I suspect this is happening because of the things changed between v0.1.23-v0.1.24.

I'm not sure how cargo-chef works internally so I cannot debug this further for now. Any ideas about how to fix this?

Panic is triggered here. According to the cargo docs, when the path field isn't included it is assumed to be the inferred path. I think this tool should follow the same spec.

This could perhaps be a broader issue with cargo-manifest and the way autoset() works.

difference is unmaintained

The author of the difference crate is unresponsive.

Maintained alternatives:

• pretty_assertions

• dissimilar

• treediff

• diffus

See advisory page for additional details.

This is a just a feature request to ask: would it be possible to have tagged versions in docker registry? This would help with caching the container since "latest" may always get downloaded