-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
COPY resolves symlinks it shouldn't try to resolve #1111
Comments
FWIW, this was probably introduced by #943 . |
@gilbsgilbs Thanks for the issue. 1. Copying a dead symlink throws an error.We changed copy to be as close to Dockerfile
My workdir
Dockerbuild log
2. Copying a single symlink creates a regular file.We also made changes to make
My dir
Run docker build
Then, i exploded the built image.
If you see the 3. Copying a directory with symlinks preserves symlinksHowever, if you copy a directory, then symlinks are preserved.
My dir
Build Docker image
Exploded image tar
In this case,
My workdir
Docker build
Exploded tar
|
I'm also seeing build failures that are likely caused by this when using |
@WestonThayer can you please provide your dockerfile? I am not very familiar with |
@tejal29 I agree that Kaniko is closer to Docker's behavior in the cases you described and that the title of this issue may be slightly incorrect (I'll fix it). But I insist, the case I gave in the original post still is a regression regarding docker 19.03 and kaniko 0.17.1 behavior. Kaniko v0.18.0 tries to resolve some symlinks it shouldn't resolve. The Case 0: dead symlinkSetup
docker buildworks 👇
Kaniko v0.18.0Crashes 👇
Kaniko v0.17.1works 👇
Case 1: good symlinkEnvironment
docker buildDoesn't crash and doesn't resolve the symlink
kaniko v0.18.0Doesn't crash but resolves the symlink:
kaniko v0.17.1Doesn't crash and doesn't resolve the symlink:
Let me know if I can provide any further information that may help you. |
yes i am. The reason why we made that change was to mimic what docker does and picked up the regression. I will work on fixing it and fixing the tests. |
Thanks. Sorry for the misunderstanding. Given that you removed the |
No worries at all. I fixed up my PR to revert back to old behavior.
|
Thank you. I can confirm this issue is fixed on |
The integration test is failing probably due to incorrect permissions. |
I can also confirm I'm not having much luck getting this down to a minimal repro, but here's the general idea. Dockerfile: FROM node:10-alpine
# Take advantage of staged Docker builds by taking care of npm installs
# separately
# This is a basic NPM package with it's own dependencies
WORKDIR /usr/src/packages/@company/backend-shared
COPY ./packages/@company/backend-shared/package*.json ./
RUN npm install
# This is a Node app that ran `npm install ../../packages/@company/backend-shared`,
# which creates a symlink from
# `/usr/src/services/backend/node_modules/@company/backend-shared`
# to
# `/usr/src/packages/@company/backend-shared`
WORKDIR /usr/src/services/backend/
COPY ./services/backend/package*.json ./
RUN npm install
# Copy dependency source and build
WORKDIR /usr/src/packages/@company/backend-shared
COPY ./packages/@company/backend-shared/ ./
RUN npm run build
# Copy source and build
# Crashes here
WORKDIR /usr/src/services/backend Here's the error:
I tried reducing down to very basic Node modules and wasn't able to reproduce it. It could've been that I used a different path structure, different NPM dependencies, or that I was skipping the |
@WestonThayer Thanks for confirming! |
Thanks @WestonThayer The error you are seeing is due to #1112 and not due to symlinks. |
Also having symlink issues with an image containing a PHP app, where its dependency manager (Composer) will create symlinks to provided binaries. When building using Docker itself, the files are – as expected – symlinked into
When building using kaniko, the files in the
For reference, the Composer dependencies were built in a separate image, and then
EDIT: Is this this issue, or is it #437 ? |
@bramus Tried your issue on latest v0.19.0 build and it does not work. i will add a fix in next release.
|
I got this minimal Dockerfile to fail on v0.18.0 and v0.19.0 when building with target
Resulting log from
|
I tried the dockefile in #1111 (comment) |
The issue in #1111 (comment) is still not fixed. |
Do I create a separate issue? |
It tries to resolve symlinks and copy target file. If it's a dangling symlink, no cigar, docker kaputs. So solution (workaround?), copy the parent directory. Apparently then, the symlinks are copied as is. GoogleContainerTools/kaniko#1111 (comment) moby/moby#40449 (comment)
It tries to resolve symlinks and copy target file. If it's a dangling symlink, no cigar, docker kaputs. So solution (workaround?), copy the parent directory. Apparently then, the symlinks are copied as is. GoogleContainerTools/kaniko#1111 (comment) moby/moby#40449 (comment)
Actual behavior
Since v0.18.0,
COPY
tries to resolve some symlinks it shouldn't try to resolve, which is a regression.Expected behavior
I would expect kaniko to let those symlinks remain symlinks when copied in the image.
To Reproduce
For instance, we can create a symlink that points to nothing to make kaniko crash:
👇 👇 👇
If we create the symlink target, it builds successfully but the symlink is replaced with a plain file within the image:
👇 👇 👇
Whereas in v0.17.1 (or using
docker build
) the symlink is not resolved:Additional Information
This is a regression from v0.18.0. It worked properly in v0.17.1.
Note that Kaniko v0.18.0 changed the way symlinks work to better match actual Docker's behavior. That probably introduced this bug as a side-effect.
Triage Notes for the Maintainers
--cache
flagThe text was updated successfully, but these errors were encountered: