Add oci-layout to platformSpecificSource#2971
Conversation
deitch
left a comment
There was a problem hiding this comment.
@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
},
}|
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's #2926 . Restarted |
|
@giggsoff here is the You should be able either to extend 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 |
oci-layout source is platform-scpecific, we should use provided platform to resolve correct image. Signed-off-by: Petr Fedchenkov <[email protected]>
09af600 to
9447ace
Compare
|
@tonistiigi test is ready. |
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. |
|
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 |
Dockerfile: update to docker v28.0.0-rc.1
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)