Hide Forgot
The router build, when run against a 4.3 build cluster (instead of api.ci 3.11 cluster) failed to put a source file into the right path in the image. https://prow.svc.ci.openshift.org/view/gcs/origin-ci-test/pr-logs/pull/openshift_router/94/pull-ci-openshift-router-master-e2e-aws/333 STEP 4: COPY images/router/haproxy/* /var/lib/haproxy/ Should put conf/haproxy-config.template into /var/lib/haproxy/conf/haproxy-config.template (and does on 3.11) But in 4.3: https://storage.googleapis.com/origin-ci-test/pr-logs/pull/openshift_router/94/pull-ci-openshift-router-master-e2e-aws/333/artifacts/e2e-aws/pods/openshift-ingress_router-default-6896776f44-58vn9_router.log error: open /var/lib/haproxy/conf/haproxy-config.template: no such file or directory While inspecting the image the file is in /var/lib/haproxy/ instead. This must be fixed before we can move jobs to 4.3 cluster. It is also a serious regression and would block buildah use in osbs
the described behavior appears to be consistent with docker build: $ tree . ├── Dockerfile └── foo └── dir └── file 2 directories, 2 files $ docker build . Sending build context to Docker daemon 4.096kB Step 1/4 : FROM centos ---> 0f3e07c0138f Step 2/4 : COPY foo/* /tmp ---> Using cache ---> 85811f7b6993 Step 3/4 : RUN cat /tmp/file ---> Using cache ---> cda4a2c1438a Step 4/4 : RUN cat /tmp/dir/file ---> Running in 9c831ba73fba cat: /tmp/dir/file: No such file or directory so i'm surprised this would have behaved differently in 3.11 unless imagebuilder was behavior in a way that's not aligned w/ docker.
I'm going to assign this one to Dan to let him decide on how to proceed.
(for now we are proceeding w/ updating our dockerfiles that are impacted by this to not use wildcards, so that however this is resolved, they should work)
Tom this looks like a bug in Buildah?
it's debatable if it's a bug. Buildah is matching Docker's behavior on this, so changing it could break people. But Clayton has expressed an interest in at least having a buildah flag for choosing whether you want "proper" behavior or "broken docker compatible" behavior. see also: https://bugzilla.redhat.com/show_bug.cgi?id=1810181 and https://bugzilla.redhat.com/show_bug.cgi?id=1810709
Dan I'm not sure I'd call this a bug, but to do the correction that Ben is talking about I'm pretty sure would have to happen in the Buildah space.
As the behavior in OCP 3.11 does not correlate with Docker's, and Buildah's design center is to not create a difference in runtime behavior between Docker and Buildah, we're considering this an RFE. As such, we've created an internal card to track the work to add a flag to emulate the old behavior and it will be addressed in a future release.