Skip to content

dispatcher: honor default builtin-args while processing FROM --platform=#224

Merged
openshift-merge-robot merged 1 commit intoopenshift:masterfrom
flouthoc:honor-builtinargs-inline-from
May 2, 2022
Merged

dispatcher: honor default builtin-args while processing FROM --platform=#224
openshift-merge-robot merged 1 commit intoopenshift:masterfrom
flouthoc:honor-builtinargs-inline-from

Conversation

@flouthoc
Copy link
Copy Markdown
Contributor

@flouthoc flouthoc commented Apr 4, 2022

While processing inline --platform= in FROM , imagebuilder ignores
default builtinArgs so for example if user wants to use inbuilt default arg
FROM --platform=$BUILDPLATFORM it should automatically replace it with
default value of BUILDPLATFORM.

Fixes

FROM --platform=$BUILDPLATFORM busybox
RUN echo "do something"

While processing inline `--platform=` in FROM , imagebuilder ignores
default builtinArgs so for example if user wants to use inbuilt default arg
`FROM --platform=$BUILDPLATFORM` it should automatically replace it with
default value of BUILDPLATFORM.

Signed-off-by: Aditya R <arajan@redhat.com>
@flouthoc
Copy link
Copy Markdown
Contributor Author

flouthoc commented Apr 4, 2022

@nalind @rhatdan @TomSweeneyRedHat PTAL

@openshift-ci
Copy link
Copy Markdown
Contributor

openshift-ci bot commented Apr 4, 2022

@flouthoc: all tests passed!

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@rhatdan
Copy link
Copy Markdown
Contributor

rhatdan commented Apr 4, 2022

LGTM
@nalind PTAL

return fmt.Errorf("Windows does not support FROM scratch")
}
}
defaultArgs := envMapAsSlice(builtinBuildArgs)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are the default values all correct when --platform is specified differently for different stages?

Copy link
Copy Markdown
Contributor Author

@flouthoc flouthoc Apr 5, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nalind mostly we only use $BUILDPLATFORM or $TARGETPLATFORM in inline platform syntax so yes default values are correct for different stages. However there is still a small issue with the way buildah populates $TARGETPLATFORM but its a small fix on buildah side not on imagebuilder side and might not be relevant to this PR.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Created a PR in buildah which exercises this and fixes $TARGETPLATFORM issue: containers/buildah#3899

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about the dockerclient client?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nalind For dockerclient we are already setting args correctly so $BUILDPLATFORM will be set correctly but other options like $TARGETPLATFORM will be only exercised by docker deamon if "features": { "buildkit": true } is enabled on the server side. So if docker daemon is running without buildkit certain things will be no-op but I think imagebuilder can not help a lot in such cases.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nalind For dockerclient we are already setting args correctly so $BUILDPLATFORM will be set correctly but other options like $TARGETPLATFORM will be only exercised by docker deamon if "features": { "buildkit": true } is enabled on the server side. So if docker daemon is running without buildkit certain things will be no-op but I think imagebuilder can not help a lot in such cases.

Its pretty much like above everything works fine except its just that $TARGETPLATFORM might be no-op depending upon the fact if dockerserver supports buildkit or not but I also think this part might be out of the scope of this PR itself.

But PR only talks about implementation of FROM --platform= which works fine for dockerclient and we added implementation for dockerclient here: #212

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The docker daemon doesn't evaluate the Dockerfile, we do.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The docker daemon doesn't evaluate the Dockerfile, we do.

Oh my bad i mixed things, if we use TARGETPLATFORM as -build-arg with imagebuilder it will work but we can't expect $TARGETPLATFORM to get correctly populated cause we don't have cli arg like buildah build --platform or docker build --platform in imagebuilder to correctly set the value of TARGETPLATFORM correct me if i got this wrong.

So its just that with imagebuilder it is expected from user to set the value of TARGETGETPLATFORM using -build-arg otherwise there is no way set the correct value of TARGETPLATFORM and default value is always https://github.com/openshift/imagebuilder/blob/master/dispatchers.go#L35

I have a feeling that this is just expected behavior and I'm overthinking this.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't TAGETGETPLATFORM just default to the local platform then?

Copy link
Copy Markdown
Contributor Author

@flouthoc flouthoc Apr 12, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rhatdan Yes It defaults to local then.

@TomSweeneyRedHat
Copy link
Copy Markdown
Contributor

LGTM
if @nalind is happy with this.

@flouthoc
Copy link
Copy Markdown
Contributor Author

flouthoc commented Apr 7, 2022

@nalind Could PTAL again.

@rhatdan
Copy link
Copy Markdown
Contributor

rhatdan commented Apr 12, 2022

/approve
LGTM

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Apr 12, 2022
@flouthoc
Copy link
Copy Markdown
Contributor Author

@nalind @rhatdan Performed conformance test on this PR with buildkit enabled.

with and without below diff I got same output as: https://pastebin.com/raw/mrb63TWE

diff --git a/dockerclient/conformance_test.go b/dockerclient/conformance_test.go
index 66508f3..5585c9c 100644
--- a/dockerclient/conformance_test.go
+++ b/dockerclient/conformance_test.go
@@ -142,7 +142,7 @@ func TestCopyFrom(t *testing.T) {
                        e.Out, e.ErrOut = out, out
                        b := imagebuilder.NewBuilder(nil)
                        dockerfile := fmt.Sprintf(`
-                               FROM busybox AS base
+                               FROM --platform=$BUILDPLATFORM busybox AS base
                                RUN %s
                                FROM busybox
                                %s

Two tests always fail for me even on the master branch without this PR and with or without buildkit enabled ( also both tests seems unrelated to this PR )

  • TestMount
  • TestConformanceInternal/novolume

@nalind
Copy link
Copy Markdown
Member

nalind commented Apr 29, 2022

A chmod -R go-w ./dockerclient/testdata is generally needed before running the conformance tests, as they make assumptions about permissions of files in the source tree which are not always correct.

@flouthoc
Copy link
Copy Markdown
Contributor Author

Thanks @nalind after chmod -R go-w ./dockerclient/testdata TestMount passes now just TestConformanceInternal/novolume fails for me both on this PR and master branch as well.

Output: https://pastebin.com/raw/HVGGGAya

Independent run for TestConformanceInternal/novolume

go test -v -tags conformance -timeout 3h ./dockerclient -run=TestConformanceInternal/novolume
=== RUN   TestConformanceInternal
=== RUN   TestConformanceInternal/novolume
    conformance_test.go:1068: conformance-dockerbuild-28-docker-0-5 and conformance-dockerbuild-28-direct-0-5 differ at var/lib/not-in-this-image/:
        &tar.Header{Typeflag:0x35, Name:"var/lib/not-in-this-image/", Linkname:"", Size:0, Mode:17389, Uid:0, Gid:0, Uname:"", Gname:"", ModTime:time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC), AccessTime:time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC), ChangeTime:time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC), Devmajor:0, Devminor:0, Xattrs:map[string]string(nil), PAXRecords:map[string]string(nil), Format:2}
        &tar.Header{Typeflag:0x35, Name:"var/lib/not-in-this-image/", Linkname:"", Size:0, Mode:16877, Uid:0, Gid:0, Uname:"", Gname:"", ModTime:time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC), AccessTime:time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC), ChangeTime:time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC), Devmajor:0, Devminor:0, Xattrs:map[string]string(nil), PAXRecords:map[string]string(nil), Format:2}
    conformance_test.go:1068: conformance-dockerbuild-28-docker-0-5 and conformance-dockerbuild-28-direct-0-5 differ at var/lib/:
        &tar.Header{Typeflag:0x35, Name:"var/lib/", Linkname:"", Size:0, Mode:17389, Uid:0, Gid:0, Uname:"", Gname:"", ModTime:time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC), AccessTime:time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC), ChangeTime:time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC), Devmajor:0, Devminor:0, Xattrs:map[string]string(nil), PAXRecords:map[string]string(nil), Format:2}
        &tar.Header{Typeflag:0x35, Name:"var/lib/", Linkname:"", Size:0, Mode:16877, Uid:0, Gid:0, Uname:"", Gname:"", ModTime:time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC), AccessTime:time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC), ChangeTime:time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC), Devmajor:0, Devminor:0, Xattrs:map[string]string(nil), PAXRecords:map[string]string(nil), Format:2}
    conformance_test.go:1083: a(conformance-dockerbuild-28-docker-0-5)=map[] b(conformance-dockerbuild-28-direct-0-5)=map[] diff=map[var/lib/:[<0 dtrwxr-xr-x> <0 drwxr-xr-x>] var/lib/not-in-this-image/:[<0 dtrwxr-xr-x> <0 drwxr-xr-x>]]
    conformance_test.go:946: 28: full Docker build was not equivalent to squashed image metadata /tmp/dockerbuild-conformance-1936807101/Dockerfile
=== RUN   TestConformanceInternal/novolumenorun
--- FAIL: TestConformanceInternal (38.38s)
    --- FAIL: TestConformanceInternal/novolume (23.33s)
    --- PASS: TestConformanceInternal/novolumenorun (15.05s)
FAIL
FAIL	github.com/openshift/imagebuilder/dockerclient	38.386s
FAIL
make: *** [Makefile:10: test-conformance] Error 1

@nalind
Copy link
Copy Markdown
Member

nalind commented Apr 29, 2022

That's... is docker setting the sticky bit on those directories? Is this a difference in behavior between docker-with-buildkit and docker-without-buildkit?

@flouthoc
Copy link
Copy Markdown
Contributor Author

Was failing for me irrespective of the buildkit but i can confirm again.

@flouthoc
Copy link
Copy Markdown
Contributor Author

It was my docker version updating it fixed for both buildkit and regular docker.

@flouthoc
Copy link
Copy Markdown
Contributor Author

Passes now

$ sudo go test -v -tags conformance -timeout 3h ./dockerclient -run=TestConformanceInternal/novolume
=== RUN   TestConformanceInternal
=== RUN   TestConformanceInternal/novolume
=== RUN   TestConformanceInternal/novolumenorun
--- PASS: TestConformanceInternal (9.63s)
    --- PASS: TestConformanceInternal/novolume (6.67s)
    --- PASS: TestConformanceInternal/novolumenorun (2.96s)
PASS
ok  	github.com/openshift/imagebuilder/dockerclient	9.630s

@rhatdan
Copy link
Copy Markdown
Contributor

rhatdan commented May 2, 2022

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label May 2, 2022
@openshift-ci
Copy link
Copy Markdown
Contributor

openshift-ci bot commented May 2, 2022

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: flouthoc, rhatdan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-robot openshift-merge-robot merged commit 009dbc6 into openshift:master May 2, 2022
flouthoc added a commit to flouthoc/buildah that referenced this pull request May 2, 2022
Use imagebuilder which sets correct behaviour for default builtinargs
while processing inline `FROM --platform=` after openshift/imagebuilder#224

Signed-off-by: Aditya R <arajan@redhat.com>
flouthoc added a commit to flouthoc/buildah that referenced this pull request May 2, 2022
Use imagebuilder which sets correct behaviour for default builtinargs
while processing inline `FROM --platform=` after openshift/imagebuilder#224

Signed-off-by: Aditya R <arajan@redhat.com>
flouthoc added a commit to flouthoc/buildah that referenced this pull request May 2, 2022
Use imagebuilder which sets correct behaviour for default builtinargs
while processing inline `FROM --platform=` after openshift/imagebuilder#224

Signed-off-by: Aditya R <arajan@redhat.com>
flouthoc added a commit to flouthoc/buildah that referenced this pull request May 3, 2022
Use imagebuilder which sets correct behaviour for default builtinargs
while processing inline `FROM --platform=` after openshift/imagebuilder#224

Signed-off-by: Aditya R <arajan@redhat.com>
flouthoc added a commit to flouthoc/buildah that referenced this pull request May 3, 2022
Use imagebuilder which sets correct behaviour for default builtinargs
while processing inline `FROM --platform=` after openshift/imagebuilder#224

Signed-off-by: Aditya R <arajan@redhat.com>
@siretart
Copy link
Copy Markdown

siretart commented Sep 3, 2023

This patch introduces tests that fail on arm64, armhf and armel with:

On arm64:

=== RUN   TestDispatchFromFlagsAndUseBuiltInArgs
    dispatchers_test.go:798: Expected linux/arm64, to match linux/arm64/v8
--- FAIL: TestDispatchFromFlagsAndUseBuiltInArgs (0.00s)

on armel:

=== RUN   TestDispatchFromFlagsAndUseBuiltInArgs
    dispatchers_test.go:798: Expected linux/arm, to match linux/arm/v8
--- FAIL: TestDispatchFromFlagsAndUseBuiltInArgs (0.00s)

On armhf:

=== RUN   TestDispatchFromFlagsAndUseBuiltInArgs
    dispatchers_test.go:798: Expected linux/arm, to match linux/arm/v7
--- FAIL: TestDispatchFromFlagsAndUseBuiltInArgs (0.00s)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants