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.
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:
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:
2 directories, 2 files
$ docker build .
Sending build context to Docker daemon 4.096kB
Step 1/4 : FROM centos
Step 2/4 : COPY foo/* /tmp
---> Using cache
Step 3/4 : RUN cat /tmp/file
---> Using cache
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.
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.