This PR has two changes that should make cargo-chef effective for CI docker builds.
Use another image (athosturso/sqld-builder, built from Dockerfile.builder) as a base for both cargo-chef steps.
Enable registry caching for Docker layers, allowing Docker layers to be reused between runs.
The first step is necessary because we can't reuse cached layers if the previous layers have changed.
And layers that run apt update, rustup update and cargo install can invalidate those caches.
The solution is to create an external image that has a separate lifecycle and does those unreproducible operations.
If this is accepted, we should create an sqld-builder package to store images for Dockerfile.builder.
The second step generates a tag inside the package to store the build cache (see this for example).
We may choose to have a different package to store only build caches as well.
When no dependencies are changed and cargo-chef works correctly, it takes 4 minutes to build the Docker image, instead of 20.
This PR has two changes that should make
cargo-chef
effective for CI docker builds.athosturso/sqld-builder
, built fromDockerfile.builder
) as a base for bothcargo-chef
steps.The first step is necessary because we can't reuse cached layers if the previous layers have changed. And layers that run
apt update
,rustup update
andcargo install
can invalidate those caches. The solution is to create an external image that has a separate lifecycle and does those unreproducible operations.If this is accepted, we should create an
sqld-builder
package to store images forDockerfile.builder
.The second step generates a tag inside the package to store the build cache (see this for example). We may choose to have a different package to store only build caches as well.
When no dependencies are changed and
cargo-chef
works correctly, it takes 4 minutes to build the Docker image, instead of 20.