Description of problem:
Performing a build where the image source input path specified is a symlink. The extraction process appears to copy the symlink, not the content referenced by the symlink, meaning the build ultimately fails when it can't find the expected content.
This appears to be a regression from the behavior we had in 3.x when extracting image content to use for build inputs.
Steps to Reproduce:
1. Create an input image with a symlink like "/symlink" that points to "/some/file"
2. Create a build that uses the input image:
- as: someimage
- destinationDir: .
3. Make the build try to use the referenced input content as "./some/file"
build fails, "./some" is not a valid path in the input content
build succeeds, ./some/file is a valid file because the symlink was followed during content extraction/copying.
Should first confirm the behavior on 3.11 but we are seeing this as a difference in behavior when moving CI from 3.x to 4.x.
fyi we hit this because i was using an old ci-operator binary which referenced content via the symlink location. The new ci-operator binary uses the paths to the real files and thus works on 4.x clusters.
But this is still a valid bug/regression in behavior (well actually maybe we need to confirm what the 3.x behavior was...I had assumed ci-operator was always doing this and it worked on 3.x but perhaps that assumption is not valid).
Regardless it does not appear to block api.ci from moving to 4.x. (unless there are specific build configurations that do use symlinks in a way that breaks here)
specifically this change in ci-operator moved from symlink to real file:
Testing this on a local 3.11 cluster - looks like COPYing symlinks only works if:
a) The symlink and target are extracted.
b) The relative paths between the symlink and target are preserved.
I suspect this is because the source is TARed and sent as input to the docker daemon.
In 4.0 this doesn't work - buildah mounts in the local filesystem as the context for its build. So if our local file system contains a symlink with an absolute path, it will likely break.
Created attachment 1553922 [details]
relative symlink bc with source
BuildConfig with symlink image source that works on 3.11. Uses relative paths.
Created attachment 1553923 [details]
relative symlink bc no source
Build config with symlink, but only copies the link. Fails on 3.11.
Created attachment 1553925 [details]
abs symlink bc source
BuildConfig with source using absolute symlinks. Fails on 3.11, though there may be some edge cases where this succeeds.
Created attachment 1553927 [details]
abs symlink bc link only
BuildConfig with absolute symlink, no source copied. Always fails on 3.11.
Created attachment 1553931 [details]
symlink bc test case
Attached bc succeeds on 3.11, breaks on 4.1.
This is a blocker IMO - developers will extract a parent directory and not care about the content within.
Created attachment 1554339 [details]
Dockerfile for source, symlink uses a relative path
Add a test case:OCP-23174 for the bug
PR to ensure we're extracting symlinks in images correctly: https://github.com/openshift/origin/pull/22456
Moving this to MODIFIED.
Origin PR  verifies that the copy behavior is correct if the source image contains a relative symlink.
Related bug 1698152  contains the actual code fix.
Verified in version:
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.