Change platform selection logic #189
Merged
Conversation
This file contains 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
Signed-off-by: Will Murphy <will.murphy@anchore.com>
Signed-off-by: Will Murphy <will.murphy@anchore.com>
This was previously fixed by PR 152, but that PR introduced another bug. Re-implement platform defaulting after the revert of PR 152. Signed-off-by: Will Murphy <will.murphy@anchore.com>
Signed-off-by: Will Murphy <will.murphy@anchore.com>
willmurphyscode
force-pushed
the
revert-152
branch
from
596fa94 to
c0270c3
Compare
Benchmark Test ResultsBenchmark results from the latest changes vs base branch |
spiffcs
reviewed
Jun 9, 2023
There was a problem hiding this comment.
Initial nit comments added - I fully agree with the changes/reverts done to selectImageProvider - I think this clears up the messaging and intent for users and puts it in a better spot than it is currently.
For discussion points:
-
I agree and think in hindsight making
registeryimitate the docker platform selection is the wrong call. Maybe we can settle on some good language to add to some part of the documentation expressing why they're different and the intention behind the two prefix -
I think this is fine as a single PR because there is some overlap between the two and it's not and overly complex revert/change =)
-
Oh no! I should have read this before I added my nit comment - This resonates with me and I'm good with the logic of if we're deciding a default then we commit and make a choice and never error. I'm fine with it being it's own function vs a method on the config just wanted to point out the other option since it's a mutation that doesn't return anything =)
Previously, the test would loop over the RepoDigest field in the image manifest to prove that the expect digest was present. However, in some cases, the RepoDigests field can be empty. Therefore, just use the ID from the manfiest, since this seems consisent across image sources, and is always present. Signed-off-by: Will Murphy <will.murphy@anchore.com>
Signed-off-by: Will Murphy <will.murphy@anchore.com>
spiffcs
approved these changes
Jun 9, 2023
gnmahanth
pushed a commit
to deepfence/stereoscope
that referenced
this pull request
Jun 15, 2023
This reverts commit d7551b7. Defaulting to platform for all providers resulted in syft having unnecessary when pulling an image that had a particular digest, if that digest didn't match the architecture of the host running the pull. Revert commit d7551b7, which introduced that error, but then add platform defaulting logic back for the OCI Registry Provider, since defaulting there has been specifically requested. Add integ tests to cover the new behavior. Also, update integ tests to use the manifest ID for assertsion, since the RepoDigests array can be empty. Signed-off-by: Will Murphy <will.murphy@anchore.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR a couple things going on:
docker:vsregistry:from multi-platform images #149docker:vsregistry:from multi-platform images #149busybox:1.31on thelinux/s390xplatform. Previously, tests only usedlinux/amd64(which is an architecture match for many modern laptops) andlinux/arm64(which is an architecture match for M1 macs). Addinglinux/s390ximages lets us pin down the behavior of image pulling that is almost certainly cross-platform. In other words, if we only havearm64andamd64test cases, then those test cases flip-flop between cross-platform and same-platform depending on whether the contributor is on an M1 or not, but adding some tests that use a platform found in fewer development laptops gives some tests that are always cross-platform.I wanted to point out a couple things for discussion:
docker:vsregistry:from multi-platform images #149 represented incorrect behavior. I could see an argument that making theregistryprovider imitate docker's platform selection was the wrong call.docker:vsregistry:from multi-platform images #149.defaultPlatformIfNilintentionally swallows an error if it occurs. That's because we're trying to guess a default behavior here, and I don't think an attempt to infer the desired default should ever return an error.