Pre-populate cargo cache

[killercup]

Cargo's initial cloning of the registry can take a while (it's 164MB on my machine right now), so it might make sense to run something like

cargo new --quiet foo && cd foo && echo 'libc = "0.2"' >> Cargo.toml && cargo fetch --quiet

at the end of the RUN block, before printing out the versions. (Or in a new RUN block so it creates a new layer.)

[sfackler]

This is a bit of an interesting case - one of the requirements for the official images is that the builds need to be deterministic. We could potentially manually check out the index at a specific commit, but we'd need to make sure that's done in a way compatible with cargo.

In my use of Docker-based build infrastructure for Rust, I've always separately cached the index - the copy from the build that ran 30 minutes ago will be faster to update than the copy at the time we created the new Docker image.

It doesn't look like the node image tries to prepopulate the cache, and I think they may have a somewhat similar setup to cargo? https://github.com/nodejs/docker-node/blob/9c25cbe93f9108fd1e506d14228afe4a3d04108f/8.2/Dockerfile

[killercup]

Using a local cache of the index seems like the better thing to do.

Deterministic Docker images? You had me going there, Steven! No, but seriously, this is a good thing to try and I totally agree. You should probably specify the exact hash/id for the buildpack-deps image, though. People can just push another version of buildpack-deps:stretch and all your efforts were in vain.

I don't think either npm nor yarn have anything like cargo's local registry checkout (at least my ~/.npm dir only has cached download artifacts and some metric files.). What in the Dockerfile you linked makes you thing they do something similar?

[sfackler]

I believe the version of the parent image is explicitly not pinned - the images are rebuilt frequently to pick up dependency updates. There's some description of what they're looking for here: https://github.com/docker-library/official-images#repeatability.

Nothing from the Dockerfile - I just had a vague recollection that npm's dependency tool had a git-based index.

[killercup]

I believe the version of the parent image is explicitly not pinned

Huh, okay. That makes it quite hard for me to personally generate an image from the Dockerfile alone that is the same as the one on Docker Hub, but Docker Hub can track which base image they used just by looking at the layers hashes.

I just had a vague recollection that npm's dependency tool had a git-based index.

Maybe you were thinking of CocoaPods (IIRC) and it DDOSing Github? :)

---

Anyway, I think we should not try to cache the registry behind Cargo's back, so I'll close this issue.

Would be awesome to have a note on using a locally cached index in a Readme!

[ellneal]

For anyone else that lands here looking for an answer to this problem: I found the best solution was to use a volume and the $CARGO_HOME variable.

docker run --rm -ti \
    -v $(pwd):/opt/content \
    --workdir /opt/content \
    -e USER \
    -e CARGO_HOME=/opt/content/.cargo \
    --entrypoint cargo rust:latest build

This puts the cargo cache inside your working directory (keeping the cache between runs, but still isolating it per project). I advise adding this .cargo directory to your SCM ignore filters (e.g. .gitignore).