Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Auto merge of rust-lang#114763 - Kobzol:fix-ci-docker-caching, r=Mark…
…-Simulacrum CI: fix Docker layer caching As reported by `@klensy` on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/docker.20images.20always.20rebuilded), Github Actions have recently updated their Docker version from 20.x to 23.x, which enabled the BuildKit build backend by default. This broke our way of performing Docker layer caching on CI, which immediately made all non-PR CI builds (including try builds) ~1 hour longer (Docker caching didn't work on PR builds before, so it wasn't affected). The moment this started happening can be seen [here](https://github.com/rust-lang-ci/rust/actions?page=2&query=branch%3Aauto+is%3Asuccess). The problem is with the following command: ``` docker history -q rust-ci | \ grep -v missing | \ xargs docker save | \ gzip | \ $upload ``` which returns the intermediate layers as `<missing>`, if BuildKit is enabled. This was investigated by `@klensy` in rust-lang#114621. Thanks for that! I will continue experimenting with how we can enable the cache with BuildKit in rust-lang#114762, but for the time being, I think that we should just hotfix this. This PR reverts the build backend back to the old one, which fixes the caching. However, we also have to bust the cache of all Dockerfiles, otherwise caching would only start kicking in for them the next time they are updated (or the next time GH updates their docker version). Because when the Docker version was updated the last time, the Dockerfiles were cached on S3 with basically an empty cache, and unless we bust it, even after reverting to the old build engine, the CI script would just download the empty cache and rebuild the Dockerfile from scratch, thus nullifying our fix. r? `@Mark-Simulacrum`
- Loading branch information