Hide Forgot
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. How reproducible: Always 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: images: - as: someimage from: kind: DockerImage name: docker.io/my/symylink:image paths: - destinationDir: . sourcePath: /symlink 3. Make the build try to use the referenced input content as "./some/file" Actual results: build fails, "./some" is not a valid path in the input content Expected results: build succeeds, ./some/file is a valid file because the symlink was followed during content extraction/copying. Additional Info: 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: https://github.com/openshift/ci-operator/commit/35523cc58ae1674fec3791656759eb1d6c039f60#diff-dd3690bad12236edb7359fb0e2df4ccd
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] source Dockerfile 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 [1] verifies that the copy behavior is correct if the source image contains a relative symlink. Related bug 1698152 [2] contains the actual code fix. [1] https://github.com/openshift/origin/pull/22456 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1698152
Verified in version: 4.1.0-0.nightly-2019-04-22-005054 payload: registry.svc.ci.openshift.org/ocp/release@sha256:3f3628cd9b694705cb0627ce72e61932df5d9938a291fabba1ed691230f7b548
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. https://access.redhat.com/errata/RHBA-2019:0758