OCI Source ignores WORKDIR/WorkingDir

[andsens]

Buildx version: da1f4b84969c56dd6960d1f270a365730ad8ef00 (v0.9.0-rc2)
Buildkit version: 7b2c27c

When sourcing from an OCI layout, the WORKDIR of that container is ignored.

In essence, exporting this as an oci tar:

FROM alpine
RUN mkdir /somedir
WORKDIR /somedir
RUN echo some content > test

and then extracting it and referencing the dir with --build-context="workdir-reproduce=oci-layout://...@sha256..." when building this:

FROM workdir-reproduce
RUN cat test

will fail, because the workdir is / instead of /somedir.

Looking at the commit history I believe @deitch would know what's up here?

Here is a minimal reproduce that can be copied and run directly (only prerequisite is a new enough buildx):

#!/usr/bin/env bash
set -e
# Buildx version: da1f4b84969c56dd6960d1f270a365730ad8ef00 (Follow https://github.com/docker/buildx/tree/da1f4b84969c56dd6960d1f270a365730ad8ef00#building to install, use `docker buildx bake "https://github.com/docker/buildx.git#v0.9.0-rc2"` for exact version)
# Buildkit version: 7b2c27c98ce623104caf65846d99774555999fa4
BUILDKIT_IMAGE_DIGEST=sha256:36a1fde1b4508c9981a8a9999864844f581c8fa0ade5334f16a0817be2d9408a

docker buildx create --name workdir-reproduce --driver docker-container --driver-opt=image=moby/buildkit@$BUILDKIT_IMAGE_DIGEST >/dev/null
trap "docker buildx rm workdir-reproduce 2>/dev/null" EXIT

oci_path=$PWD/workdir-reproduce
mkdir "$oci_path"
trap 'docker buildx rm workdir-reproduce 2>/dev/null; rm -rf "$oci_path.tar" "$oci_path"' EXIT

docker buildx build -q --builder workdir-reproduce --output="type=oci,dest=$oci_path.tar" - <<<"
FROM alpine
RUN mkdir /somedir
WORKDIR /somedir
RUN echo some content > test" >/dev/null

tar -xf "$oci_path.tar" -C "$oci_path"
printf "WorkingDir in manifest: '%s'\n\n" "$(jq -r .config.WorkingDir "$oci_path/$(jq -r '.[0].Config' "$oci_path/manifest.json")")"
oci_digest=$(jq -r '.manifests[0].digest' "$oci_path/index.json")
docker buildx build --builder workdir-reproduce --load --tag workdir-reproduce --build-context="workdir-reproduce=oci-layout://$oci_path@$oci_digest" - <<<"
FROM workdir-reproduce
RUN pwd >&2; cat test" || true

printf "\nbuildx & buildkit versions\n--------------------------\n"
docker buildx version
docker exec buildx_buildkit_workdir-reproduce0 buildctl --version

Output:

$ ./reproduce.sh
WorkingDir in manifest: '/somedir'

[+] Building 0.2s (5/5) FINISHED
 => [internal] load .dockerignore                                                                         0.0s
 => => transferring context: 2B                                                                           0.0s
 => [internal] load build definition from Dockerfile                                                      0.1s
 => => transferring dockerfile: 83B                                                                       0.0s
 => [context workdir-reproduce] load metadata for workdir-reproduce@sha256:3a2aecaa7af10280cacd4e160b4e7  0.0s
 => [context workdir-reproduce] OCI load from client                                                      0.0s
 => => resolve oci-layout/dummy@sha256:3a2aecaa7af10280cacd4e160b4e7ca2b15027ae7a776fed04c5b65ca36f885f   0.0s
 => ERROR [1/2] RUN pwd >&2; cat test                                                                     0.1s
------
 > [1/2] RUN pwd >&2; cat test:
#0 0.053 /
#0 0.053 cat: can't open 'test': No such file or directory
------
Dockerfile:3
--------------------
   1 |
   2 |     FROM workdir-reproduce
   3 | >>> RUN pwd >&2; cat test
   4 |
--------------------
ERROR: failed to solve: process "/bin/sh -c pwd >&2; cat test" did not complete successfully: exit code: 1

buildx & buildkit versions
--------------------------
github.com/docker/buildx da1f4b8 da1f4b84969c56dd6960d1f270a365730ad8ef00
buildctl github.com/moby/buildkit 7b2c27c 7b2c27c98ce623104caf65846d99774555999fa4

[andsens]

On an unrelated note: Shouldn't the input and output formats for OCI be the same? I mean, it's a simple tar extraction so it's no biggie, but the asymmetry kind of bugs me.

[jedevc]

Heya 👋

Have opened a PR to fix this, looks like a small oversight in the contextByName loader - I don't think this was deliberate, but @deitch or @tonistiigi should be able to correct me if I'm wrong, I can't see a reference to it in the review.

R.e. your second point, this sounds similar to #1219. There's also some discussion in the OCI source PR here that might be relevant. It looks to me like this is something we definitely want to support to make the OCI source feature as easy-as-possible to use.

[andsens]

Dang, that was quick :-D
Thank you!

[deitch]

looks like a small oversight in the contextByName loader

Indeed it was, and thank you for catching and fixing it.

There's also some discussion in the OCI source PR #2827 (comment) that might be relevant. It looks to me like this is something we definitely want to support to make the OCI source feature as easy-as-possible to use.

We did have that discussion; I think we all would like some consistency, but probably without breaking anything backwards compatible.