This happens for example when cache loading fails
but then fallback step execution succeeds.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
(cherry picked from commit c13f5de2fb)
When running a WORKDIR instruction, buildkit will create that folder
and chown it to the currently set user. For this, it will try to read
the /etc/passwd file to get the proper UID, and if that user is not
found in the file, the root user will be considered as the owner.
However, Windows image do not have that file, which will result in
an error while building the image. We can consider not finding
the /etc/passwd file as the same as not finding the user in the file,
which would solve this issue.
Signed-off-by: Claudiu Belu <cbelu@cloudbasesolutions.com>
Finalize was only used outside the cache package in one place, which
called it with the commit arg set to false. The code path followed
when commit==false turned out to essentially be a no-op because
it set "retain cache" to true if it was already set to true.
It was thus safe to remove the only external call to it and remove it
from the interface. This should be helpful for future efforts to
simplify the equal{Mutable,Immutable} fields in cacheRecord, which exist
due to the "lazy commit" feature that Finalize is tied into.
Signed-off-by: Erik Sipsma <erik@sipsma.dev>
Allow include and exclude patterns to be specified for the "copy" op,
similarly to "local".
Depends on https://github.com/tonistiigi/fsutil/pull/101
Signed-off-by: Aaron Lehmann <alehmann@netflix.com>
Relates to a82fff6377/docs/packages.md (proxies)
> (..) the first four of these are the standard built-in build-arg options
> available for `docker build`
> (..) The last, `all_proxy`, is a standard var used for socks proxying. Since
> it is not built into `docker build`, if you want to use it, you will need to
> add the following line to the dockerfile:
>
> ARG all_proxy
Given the we support all other commonly known proxy env-vars by default, it makes
sense to add this one as well.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
A bug in cloneExecOp prevented mounts from being included in the digest
computed for the execOp cache map. This could lead to an exec being
wrongly cached when a different mount was used for a subsequent
execution.
Repro case:
https://gist.github.com/aaronlehmann/cfeaefc028df8127fb85b9b5f9125f2d
In this example, pass2 should generate an empty diff because the /from
and /to mounts are the same busybox image. But before the fix, it uses
the cached result from pass1 (with different mounts) instead.
Signed-off-by: Aaron Lehmann <alehmann@netflix.com>
I saw these, and there was no comment in the code explaining if there was a reason
for this; these were added in 2be999ba52, but couldn't
find a mention about these particular lines in the review comments, and I couldn't
think of a special reason for it ':-)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
In some cases edges that depend on each other
can have identical cache keys. This happens for
example when empty layers are optimized out by
the differ between identical commands. We need to
detect this case and avoid merge.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Tonis Tiigi
Maxime Lagresle
Erik Sipsma
Claudiu Belu
Morlay
ktock
Akihiro Suda
Akihiro Suda
Cory Bennett
Sebastiaan van Stijn
Aaron Lehmann
Edgar Lee
Vlad A. Ionescu