Add oci-layout to platformSpecificSource

[giggsoff]

oci-layout source is platform-scpecific, we should use provided
platform to resolve correct image.

Now I can see the problem with building for another arch and seems we reuse image with host arch for build: linuxkit/linuxkit#3797 (comment)

[deitch]

@giggsoff explained this in detail to me, and was able to replicate it.

Because it does not provide a platform (i.e. ignores it), it always looks for the one the builder is running on, even if you requested a different one via:

SolveOpt{
		FrontendAttrs: map[string]string{
                    "platform": "linux/arm64", // or whatever
                },
	}

[tonistiigi]

Not a blocker for this PR, but could we make this case covered by integration tests?

[giggsoff]

Not a blocker for this PR, but could we make this case covered by integration tests?

Sure, will try to add the test for this specific case.
It seems that not all current tests passed, not sure that failed TestClientGatewayIntegration/TestClientGatewaySlowCacheExecError/worker=containerd-rootless test is related with changes.

[tonistiigi]

test is related with changes.

It's #2926 . Restarted

[deitch]

@giggsoff here is the client_test.go for the PR that created OCI source.

You should be able either to extend testOCILayoutSource() to include specific arch use case, or create a separate test.

I can see perhaps including arch-specific information in the built image, e.g. adding a line here where we check the results here. Might want to build for multiple platforms by putting this in a for loop, each one checking the expected platform in the file. That way you know you are pulling the right one.

[giggsoff]

@tonistiigi test is ready.
@deitch thanks for recommendations. Decided to add another test for this case.

[sudo-bmitch]

oci-layout source is platform-scpecific, we should use provided platform to resolve correct image.

OCI Layout can include multiplatform images. I haven't dug through the changes here, but is this related to how the Layout is generated, and do we want to support other sources of a Layout?

More generally, we probably want to warn or fail when a single platform source is used and the platform does not match the requirements for the build. I think that's being looked at in #2946.

[deitch]

The oci layout just treats it like a registry. Give it the digest, it sends back that manifest. From that point on, it's the same actual code we use for the registry: resolve the arch, find the manifest, etc