-
Notifications
You must be signed in to change notification settings - Fork 473
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 miss using COPY --chmod to get equal permissions in image #1311
Labels
Comments
Cache checksums happen before the actual copy with specific parameters is executed. This would require a specific buildkit optimization where copy steps asks for a custom checksum implementation based on its parameters. |
wato-github-automation bot
pushed a commit
to WATonomous/watcloud-website
that referenced
this issue
Sep 17, 2024
## Description In WATonomous/infra-config#3175, we attempted to use `COPY --chmod` to allow caching for different systems (with different `umask`s). However, it didn't work. It seems that Docker calculates whether a file has changed without accounting for the `--chmod` (it's also mentioned [here](docker/buildx#1311)). This PR reverts that change and documents this quirk. ## Checklist - [x] I have read and understood the [WATcloud Guidelines](https://cloud.watonomous.ca/docs/community-docs/watcloud/guidelines) - [x] I have performed a self-review of my code - [ ] POST-MERGE: investigate additional improvements: WATonomous/infra-config#3178
wato-github-automation bot
pushed a commit
to WATonomous/watcloud-website
that referenced
this issue
Sep 17, 2024
…g from build context (#3179) ## Description In WATonomous/infra-config#3176, we documented a manual procedure to fix cache invalidation issues for the provisioner container. However, there's a workaround: use a lightweight intermediate stage to serve as the courier between the context. The workaround comes from [here](devcontainers/cli#153 (comment)). This PR implements the workaround and updates the docs to reflect this. **How it works**: Docker computes hashes for the input to each layer to determine whether that layer can use the cache. Previously, the permission bits on the computer that built the cache and my personal environment were different. This resulted in the hash being different, thus invalidating the cache. `COPY --chmod` doesn't help either because the hash is computed [without taking into account the parameters](docker/buildx#1311). In this PR, we implement a workaround, where we use an extremely lightweight stage (`FROM scratch` with only `COPY` statements) to import files and set permissions from the build context. We don't care whether this stage runs or gets cached, because it's very lightweight. At build-time, if we are lucky that our system has the same permissions as the cache build environment, then this stage will be cached. If not, this stage will run. Regardless, the output of this stage will remain the same if the file is unchanged. This property allows Docker to continue subsequent steps with cache. Tested to work with the existing cache when using permission 644. This PR changes the permissions to 400 to be a bit more strict. Resolves WATonomous/infra-config#3178 ## Checklist - [x] I have read and understood the [WATcloud Guidelines](https://cloud.watonomous.ca/docs/community-docs/watcloud/guidelines) - [x] I have performed a self-review of my code
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I'm trying to use
COPY --chmod
to still get a cache hit when the permissions on the host filesystem change. (We want to prebuild images in CI for use on developer machines: devcontainers/cli#153.)Steps to reproduce on a single Linux machine:
Dockerfile
and afile.txt
next to it:docker system prune --all
to start fresh.chmod g-w file.txt && docker buildx build --progress plain .
. (A second run shows that all layers are coming from the cache.)chmod g+w file.txt && docker buildx build --progress plain .
(Note the changed group write permission on the host file.)COPY
shows a cache miss when a cache hit is expect. It looks as if the host's file permission go into the cache checksum instead of the--chmod
permissions.Docker and BuildKit versions:
The text was updated successfully, but these errors were encountered: