Fix builder inconsistent error on buggy platform#41873
Merged
Merged
Conversation
cpuguy83
force-pushed
the
fix_builder_inconsisent_platform
branch
from
January 13, 2021 19:03
de396ea to
e78741f
Compare
thaJeztah
reviewed
Jan 13, 2021
thaJeztah
approved these changes
Jan 14, 2021
thaJeztah
left a comment
thaJeztah
left a comment
Member
There was a problem hiding this comment.
SGTM
@tonistiigi @tianon PTAL
thaJeztah
reviewed
Jan 14, 2021
Member
There was a problem hiding this comment.
Suggested change
| `, platforms.Format(p), platforms.Format(imgPlat), name) | |
| `, platforms.Format(p), platforms.Format(imgPlat), name) |
cpuguy83
force-pushed
the
fix_builder_inconsisent_platform
branch
from
January 14, 2021 19:18
e78741f to
ae8abfc
Compare
Member
|
@tonistiigi ptal |
tonistiigi
reviewed
Jan 14, 2021
cpuguy83
force-pushed
the
fix_builder_inconsisent_platform
branch
from
January 14, 2021 19:39
ae8abfc to
1708731
Compare
tonistiigi
approved these changes
Jan 14, 2021
thaJeztah
added
area/images
Member
When pulling an image by platform, it is possible for the image's configured platform to not match what was in the manifest list. The image itself is buggy because either the manifest list is incorrect or the image config is incorrect. In any case, this is preventing people from upgrading because many times users do not have control over these buggy images. This was not a problem in 19.03 because we did not compare on platform before. It just assumed if we had the image it was the one we wanted regardless of platform, which has its own problems. Example Dockerfile that has this problem: ```Dockerfile FROM --platform=linux/arm64 k8s.gcr.io/build-image/debian-iptables:buster-v1.3.0 RUN echo hello ``` This fails the first time you try to build after it finishes pulling but before performing the `RUN` command. On the second attempt it works because the image is already there and does not hit the code that errors out on platform mismatch (Actually it ignores errors if an image is returned at all). Must be run with the classic builder (DOCKER_BUILDKIT=0). Signed-off-by: Brian Goff <[email protected]>
cpuguy83
force-pushed
the
fix_builder_inconsisent_platform
branch
from
January 14, 2021 21:46
1708731 to
3996953
Compare
Member
Author
|
Rebased. |
thaJeztah
approved these changes
Jan 21, 2021
thaJeztah
left a comment
thaJeztah
left a comment
Member
There was a problem hiding this comment.
LGTM
s390x failure is unrelated
This was referenced Apr 26, 2021
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
addresses docker/for-linux#1170
When pulling an image by platform, it is possible for the image's
configured platform to not match what was in the manifest list.
The image itself is buggy because either the manifest list is incorrect
or the image config is incorrect. In any case, this is preventing people
from upgrading because many times users do not have control over these
buggy images.
This was not a problem in 19.03 because we did not compare on platform
before. It just assumed if we had the image it was the one we wanted
regardless of platform, which has its own problems.
Example Dockerfile that has this problem:
This fails the first time you try to build after it finishes pulling but
before performing the
RUNcommand.On the second attempt it works because the image is already there and
does not hit the code that errors out on platform mismatch (Actually it
ignores errors if an image is returned at all).
Must be run with the classic builder (DOCKER_BUILDKIT=0).
This should mostly be safe (and certainly safer than 19.03) since we only check this immediately after a pull.
Example output before the fix:
Example output after the fix: