Skip to content
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

Open
chrmarti opened this issue Sep 9, 2022 · 1 comment
Open

Cache miss using COPY --chmod to get equal permissions in image #1311

chrmarti opened this issue Sep 9, 2022 · 1 comment

Comments

@chrmarti
Copy link

chrmarti commented Sep 9, 2022

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:

  • Create the below Dockerfile and a file.txt next to it:
# syntax=docker/dockerfile:1.4
FROM ubuntu:latest
COPY --chmod=0600 ./file.txt /
  • Remove all containers and run docker system prune --all to start fresh.
  • Run chmod g-w file.txt && docker buildx build --progress plain .. (A second run shows that all layers are coming from the cache.)
  • Run 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:

github.com/docker/buildx v0.9.1 ed00243a0ce2a0aee75311b06e32d33b44729689
Client: Docker Engine - Community
 Version:           20.10.17
 API version:       1.41
 Go version:        go1.17.11
 Git commit:        100c701
 Built:             Mon Jun  6 23:02:46 2022
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.17
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.17.11
  Git commit:       a89b842
  Built:            Mon Jun  6 23:00:51 2022
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.8
  GitCommit:        9cd3357b7fd7218e4aec3eae239db1f68a5a6ec6
 runc:
  Version:          1.1.4
  GitCommit:        v1.1.4-0-g5fd4c4d
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
@tonistiigi
Copy link
Member

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
Projects
None yet
Development

No branches or pull requests

3 participants