-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cache CI Docker images in ghcr registry #119290
Conversation
This comment has been minimized.
This comment has been minimized.
9e9604b
to
6f90144
Compare
@bors try This broadly looks fine to me -- is there a reason I don't see try builds etc. on this PR? I think we should test out that it works on try + local builds (src/ci/docker/run.sh from your laptop or w/e), and perhaps get rustup CI working, and then we can merge. |
…try> Cache CI Docker images in ghcr registry This PR changes the way `rust-lang` caches Docker images used in CI workflows. Before, the intermediate Docker layers were manually exported from `docker history` and backed up in S3. However, this approach doesn't work any more with the Docker version used by GitHub Actions since August 2023. We had to revert to disabling Docker BuildKit to make the old caching work, but this workaround will stop working eventually, after GitHub updates Docker again and the old build backend will be removed. This PR changes the caching to use [Docker caching](https://docs.docker.com/build/cache/) instead. There are several backends for the cache, for our use-case S3 and Docker registry makes sense. This PR uses the Docker registry backend and uses the ghcr.io registry. The caching creates a Docker image labeled `rust-ci`, which is currently stored to the `ghcr.io/rust-lang-ci` package registry. This image appears [here](https://ghcr.io/rust-lang-ci/rust-ci). The image is stored in `rust-lang-ci` and not `rust-lang`, because `try` and `auto` builds run in the context of that repository, so the used `GITHUB_TOKEN` has permissions for it (unlike for `rust-lang`). For pull request CI runs, the provided `GITHUB_TOKEN` reduces its permissions automatically to `packages: read`, which means that we won't be able to write the Docker image. If we're not able to write, we won't have anything to read. So I disabled the caching entirely for PR runs (it makes it slightly faster to build the Docker image if we don't have to deal with exporting and using a separate build driver). Note that before this PR, we also weren't able to read or write the cache on PR runs. Related issue: rust-lang/infra-team#81 r? `@Mark-Simulacrum`
I tested a try build on a different PR, but we should of course also try it here. What I'm struggling with currently is how to use the cache as a |
☀️ Try build successful - checks-actions |
@bors try |
…try> Cache CI Docker images in ghcr registry This PR changes the way `rust-lang` caches Docker images used in CI workflows. Before, the intermediate Docker layers were manually exported from `docker history` and backed up in S3. However, this approach doesn't work any more with the Docker version used by GitHub Actions since August 2023. We had to revert to disabling Docker BuildKit to make the old caching work, but this workaround will stop working eventually, after GitHub updates Docker again and the old build backend will be removed. This PR changes the caching to use [Docker caching](https://docs.docker.com/build/cache/) instead. There are several backends for the cache, for our use-case S3 and Docker registry makes sense. This PR uses the Docker registry backend and uses the ghcr.io registry. The caching creates a Docker image labeled `rust-ci`, which is currently stored to the `ghcr.io/rust-lang-ci` package registry. This image appears [here](https://ghcr.io/rust-lang-ci/rust-ci). The image is stored in `rust-lang-ci` and not `rust-lang`, because `try` and `auto` builds run in the context of that repository, so the used `GITHUB_TOKEN` has permissions for it (unlike for `rust-lang`). For pull request CI runs, the provided `GITHUB_TOKEN` reduces its permissions automatically to `packages: read`, which means that we won't be able to write the Docker image. If we're not able to write, we won't have anything to read. So I disabled the caching entirely for PR runs (it makes it slightly faster to build the Docker image if we don't have to deal with exporting and using a separate build driver). Note that before this PR, we also weren't able to read or write the cache on PR runs. Related issue: rust-lang/infra-team#81 r? `@Mark-Simulacrum`
☀️ Try build successful - checks-actions |
@rustbot author Let me know if I can/should try to help here, otherwise will put this in waiting on author for now. |
7dae399
to
41ef4a5
Compare
@bors try |
41ef4a5
to
8bb6a1b
Compare
Cache CI Docker images in ghcr registry This PR changes the way `rust-lang` caches Docker images used in CI workflows. Before, the intermediate Docker layers were manually exported from `docker history` and backed up in S3. However, this approach doesn't work any more with the Docker version used by GitHub Actions since August 2023. We had to revert to disabling Docker BuildKit to make the old caching work, but this workaround will stop working eventually, after GitHub updates Docker again and the old build backend will be removed. This PR changes the caching to use [Docker caching](https://docs.docker.com/build/cache/) instead. There are several backends for the cache, for our use-case S3 and Docker registry makes sense. This PR uses the Docker registry backend and uses the ghcr.io registry. The caching creates a Docker image labeled `rust-ci`, which is currently stored to the `ghcr.io/rust-lang-ci` package registry. This image appears [here](https://ghcr.io/rust-lang-ci/rust-ci). The image is stored in `rust-lang-ci` and not `rust-lang`, because `try` and `auto` builds run in the context of that repository, so the used `GITHUB_TOKEN` has permissions for it (unlike for `rust-lang`). For pull request CI runs, the provided `GITHUB_TOKEN` reduces its permissions automatically to `packages: read`, which means that we won't be able to write the Docker image. If we're not able to write, we won't have anything to read. So I disabled the caching entirely for PR runs (it makes it slightly faster to build the Docker image if we don't have to deal with exporting and using a separate build driver). Note that before this PR, we also weren't able to read or write the cache on PR runs. Related issue: rust-lang/infra-team#81 r? `@Mark-Simulacrum`
8bb6a1b
to
53a9eae
Compare
@bors try |
The Rustup part of this change is at: rust-lang/rustup#3648. Local build seems to work. |
This comment has been minimized.
This comment has been minimized.
…ark-Simulacrum Cache CI Docker images in ghcr registry This PR changes the way `rust-lang` caches Docker images used in CI workflows. Before, the intermediate Docker layers were manually exported from `docker history` and backed up in S3. However, this approach doesn't work any more with the Docker version used by GitHub Actions since August 2023. We had to revert to disabling Docker BuildKit to make the old caching work, but this workaround will stop working eventually, after GitHub updates Docker again and the old build backend will be removed. This PR changes the caching to use [Docker caching](https://docs.docker.com/build/cache/) instead. There are several backends for the cache, for our use-case S3 and Docker registry makes sense. This PR uses the Docker registry backend and uses the ghcr.io registry. The caching creates a Docker image labeled `rust-ci`, which is currently stored to the `ghcr.io/rust-lang-ci` package registry. This image appears [here](https://ghcr.io/rust-lang-ci/rust-ci). The image is stored in `rust-lang-ci` and not `rust-lang`, because `try` and `auto` builds run in the context of that repository, so the used `GITHUB_TOKEN` has permissions for it (unlike for `rust-lang`). For pull request CI runs, the provided `GITHUB_TOKEN` reduces its permissions automatically to `packages: read`, which means that we won't be able to write the Docker image. If we're not able to write, we won't have anything to read. So I disabled the caching entirely for PR runs (it makes it slightly faster to build the Docker image if we don't have to deal with exporting and using a separate build driver). Note that before this PR, we also weren't able to read or write the cache on PR runs. Rustup part of this change is [here](rust-lang/rustup#3648). Related issue: rust-lang/infra-team#81 r? `@Mark-Simulacrum`
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
@bors r=Mark-simulacrum (This run will fail, but I added additional logging to help me debug the used Docker version on our self-hosted runners). |
☀️ Test successful - checks-actions |
Finished benchmarking commit (7e43442): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 660.85s -> 661.466s (0.09%) |
…acrum CI: cache PR CI Docker builds An attempt to restore Docker caching for PR CI workflows that share the Docker image with an auto/try workflow. This was broken by my previous [PR](rust-lang#119290) that changed how we cache the Docker builds. [Before](rust-lang#122545): ![image](https://github.com/rust-lang/rust/assets/4539057/05e0d347-af64-4e85-bc99-0e4ac07192ec) After: ![image](https://github.com/rust-lang/rust/assets/4539057/2f657d60-b242-45eb-ac61-d8f71787edda) r? `@ghost`
…acrum CI: cache PR CI Docker builds An attempt to restore Docker caching for PR CI workflows that share the Docker image with an auto/try workflow. This was broken by my previous [PR](rust-lang#119290) that changed how we cache the Docker builds. [Before](rust-lang#122545): ![image](https://github.com/rust-lang/rust/assets/4539057/05e0d347-af64-4e85-bc99-0e4ac07192ec) After: ![image](https://github.com/rust-lang/rust/assets/4539057/2f657d60-b242-45eb-ac61-d8f71787edda) r? ``@ghost``
Rollup merge of rust-lang#122563 - Kobzol:ci-pr-caching, r=Mark-Simulacrum CI: cache PR CI Docker builds An attempt to restore Docker caching for PR CI workflows that share the Docker image with an auto/try workflow. This was broken by my previous [PR](rust-lang#119290) that changed how we cache the Docker builds. [Before](rust-lang#122545): ![image](https://github.com/rust-lang/rust/assets/4539057/05e0d347-af64-4e85-bc99-0e4ac07192ec) After: ![image](https://github.com/rust-lang/rust/assets/4539057/2f657d60-b242-45eb-ac61-d8f71787edda) r? ``@ghost``
This PR changes the way
rust-lang
caches Docker images used in CI workflows. Before, the intermediate Docker layers were manually exported fromdocker history
and backed up in S3. However, this approach doesn't work any more with the Docker version used by GitHub Actions since August 2023. We had to revert to disabling Docker BuildKit to make the old caching work, but this workaround will stop working eventually, after GitHub updates Docker again and the old build backend will be removed.This PR changes the caching to use Docker caching instead. There are several backends for the cache, for our use-case S3 and Docker registry makes sense. This PR uses the Docker registry backend and uses the ghcr.io registry.
The caching creates a Docker image labeled
rust-ci
, which is currently stored to theghcr.io/rust-lang-ci
package registry. This image appears here. The image is stored inrust-lang-ci
and notrust-lang
, becausetry
andauto
builds run in the context of that repository, so the usedGITHUB_TOKEN
has permissions for it (unlike forrust-lang
).For pull request CI runs, the provided
GITHUB_TOKEN
reduces its permissions automatically topackages: read
, which means that we won't be able to write the Docker image. If we're not able to write, we won't have anything to read. So I disabled the caching entirely for PR runs (it makes it slightly faster to build the Docker image if we don't have to deal with exporting and using a separate build driver). Note that before this PR, we also weren't able to read or write the cache on PR runs.Rustup part of this change is here.
Related issue: rust-lang/infra-team#81
r? @Mark-Simulacrum