Closed mstergianis closed 6 months ago
Great catch. That bug has been around since 2022 😄 not sure how we did not catch that earlier.
I find it a little bit odd that the default behaviour now includes fetching these layers. It roughly doubles the execution time of my example, and I'd imagine for many real world cases where a bundle contains more than one image it might be worse. Maybe consider putting the new feature behind an option?
This sounds like an oversight. We also have a flag for cosign artifacts, which defaults to true. Would it be ok if we have a flag called --layers
that also defaults to true, and you can set it to false?
When I timeboxed myself and tried to write a test I got lost in the FakeRegistry and how to describe this particular case.
This particular fake only supports one registry, which would make it complicated to test. The easier thing to do here is to create an e2e test where the setup might be easier.
PR merged
What steps did you take:
imgpkg copy
) that bundle to a second private registry. The scenario I'm simulating here is moving something from an company's internal registry, to a company's public yet authenticated registry.Here's a script that roughly sums up what I did to replicate this from scratch
What happened:
imgpkg describe
fails because it tries to list the layers of an image it can't accessWhat did you expect:
imgpkg describe
succeedsAnything else you would like to add:
FakeRegistry
and how to describe this particular case.Environment:
imgpkg --version
):Docker HUB
): I used a harbor instance and azurecr in my example/etc/os-release
): linuxVote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible" 👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you want to help working on this issue.