unresolved imports when using rust-musl-builder with cargo-chef about cargo-chef HOT 10 CLOSED

Hello all, hopefully this is helpful. I am also following along with the book and attempted to utilize cargo-chef with the rust-musl-builder. The following Dockerfile is what I came up with, and is currently working for me.

FROM ekidd/rust-musl-builder:1.50.0 AS builder-chef
USER root
RUN cargo install --version 0.1.20 cargo-chef

FROM builder-chef AS planner
WORKDIR /app
COPY . .
RUN cargo chef prepare --recipe-path recipe.json

FROM builder-chef AS builder
WORKDIR /app
COPY --from=planner /app/recipe.json recipe.json
RUN cargo chef cook --release --target x86_64-unknown-linux-musl --recipe-path recipe.json
ENV SQLX_OFFLINE true
COPY . .
RUN cargo build --release --target x86_64-unknown-linux-musl \
    && strip /app/target/x86_64-unknown-linux-musl/release/zero2prod

FROM alpine:3.13 AS runtime
RUN addgroup -S zero2prod && adduser -S zero2prod -G zero2prod
COPY --from=builder /app/target/x86_64-unknown-linux-musl/release/zero2prod /usr/local/bin/
COPY configuration configuration
ENV APP_ENVIRONMENT production
USER zero2prod
CMD ["/usr/local/bin/zero2prod"]

from cargo-chef.

TL;DR: I found my issue to be a different one, the "workaround" by @Disco-Dave is working well also on my system/code. Thanks both @LukeMathWalker and @Disco-Dave

Longer version:

While cleaning up my Dockerfile so to post it here, I had it working at some point...
I am not entirely sure what made the "unresolved imports" go away, there was surely at least one classic "error between keyboard and chair" somewhere, despite all the cache cleanings and rebuilds). Yet I found that behaviour changes depending on the absolute path of the Cargo.lock file within the container instance (maybe it is not even directly related to cargo-chef).
When Cargo.lock is at /Cargo.lock I get trouble, as of now e.g. I have

Step 11/22 : RUN cargo chef cook --release --target x86_64-unknown-linux-musl --recipe-path recipe.json
 ---> Running in 66fabfb31d55
error: failed to parse lock file at: /Cargo.lock

Caused by:
  package `cfg-if` is specified twice in the lockfile
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
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

and that of course points to the further general topic of duplicates (I checked the file, it is actually present two times with two different versions). Yet curiously enough, everything goes smoothly if the very same file is e.g. at /app/Cargo.lock

from cargo-chef.

Adding a +1 - I'm struggling with the same issue, and had to back out of using cargo chef (even though it looks great) to downgrade to the method described here:

COPY --chown=rust:rust Cargo.toml ./
COPY --chown=rust:rust Cargo.lock ./
COPY --chown=rust:rust testsuite/Cargo.toml testsuite/
COPY --chown=rust:rust testsuite/dummy_main_for_build_cache.rs testsuite/src/main.rs
RUN cargo build --release

from cargo-chef.

I also stumbled on this issue. Unluckily for me, the "workaround" by @Disco-Dave is not working on my system/code.

from cargo-chef.

Can you share your Dockerfile @michelebariani?

from cargo-chef.

I have updated the README (#90) to recommend @Disco-Dave's approach.
I'll close this issue, as the approach seems to work, but feel free to re-open if there are new edge cases that need to be considered.

from cargo-chef.

@michelebariani was you able to solve your issue?

from cargo-chef.

I get exactly same error in remote ci docker, while not getting it locally, so recipe locally contains cfg-if 2 times

package `cfg-if` is specified twice in the lockfile

from cargo-chef.

@michelebariani was you able to solve your issue?

As I wrote above, yes the workaround actually worked for me as well

from cargo-chef.

my toml not in app, so it is in subfolder of git

from cargo-chef.