Somehow the index feature did not work in here as i was not able to pull chart without specifying the version

That's mainly the reason for this change. I am not sure why that

Should we use a new header before explaining this new flag?

Also, I find this sentence confusing. What's "the original" here?

Yes I wanted to refer to helm dt unwrap oci://original_repo.
Perhaps unwrapping target ? Or what do you recommend?

Maybe something like Unwrapping a Helm chart to a different registry than the one used on relocation or Using different registries for distribution and relocation?

It would also be nice to add some context on why this is needed. Something like:

Sometimes you might need the content on the Helm chart pointing to a registry different than where the Helm chart needs to be pushed to. This is common for example on Airgap environments where a Helm chart might need to be pushed to an interim environment different from where it is meant to be consumed from, or for example in edge distribution channels where the Helm charts might need to be moved from an interim release registry into an edge registry for general public usage.

Please avoid this kind of changes (this applies to other files) so the PR only shows the code you actually changed

I guess a better parameter name would be push-container-registry, right? I mean, in a given chart there are N potential repositories published in a single registry/namespace, see:

• https://learn.microsoft.com/en-us/azure/container-registry/container-registry-concepts

Maybe. Unclear to me as the current flag for helm chart is push-chart-url ....

#93 (comment)

as oci repos are general purpose not specific to store binary images, charts, or just a file just registry might be a good option. Naming is the hardest in here. Let me know what you will like me to change and to what and I will update PR when that's defined. Thanks for having a look

I'd go for sth like this:

	cmd.PersistentFlags().StringVar(&pushContainerRegistry, "push-container-registry", pushContainerRegistry, "push the container images included in the unwrapped Helm chart to the given container registry (including namespace)")

What do you think @mpermar?

Agree. I will attempt have this clean up tomorrow. Thanks

Actually I take it back @machecazzon @juan131. The value can be both a registry and a repository so probably would need some other name like push-uri.

But, actually, while looking in detail to the naming, and this is totally my bad as I am lost touch with this project and it has evolved quite a while since I left it, I can see there is a push-chart-url which I believe it might do exactly what this PR is trying to do.

Have been thinking about this a bit more and I believe that having --values-registry could be more appropriate as is actually what I am looking for.

"Have the values of the chart to be relocated not to the unwrap target but instead the value provided by e.g --values-registry."

That's more like what I did on my first attempt to cover the use case.

Right now I have a custom build with what I need to have the desired outputs that includes this and some other changes and is not a big deal but I would prefer that this tool could support this behaviour.

Back into the naming, kaniko has this switch and it's format somehow make me think of this Thread.

https://github.com/GoogleContainerTools/kaniko?tab=readme-ov-file#flag---registry-map

Very likely I will abandon this PR and come back later with a better solution and better PR hopefully, but if wanted can still try to address this PR comments.

In regards the push-chart-url I am currently using that switch to tune the chart destination path as well as needing this same "feature". This is related to some other "issue" I have with current implementation and patched for good on my end :)

RelocateImageURL method seems that it might change the original path and have something else on the unwrap target depending on the input provided and what the image url is. This turns that image path not be the exactly the same on the destination (apart the registry bits) as the original source what I need to ensure preservation.

My current scenario: GAR Reader / GAR Writer

• GAR Reader (Virtual Repo) is a able to pull from Gitlab registry
• dev teams build their images and push to Gitlab registry
• dt is used to build a wrap on ci ensuring images exist, are pinned (lock/verify) but skip save images that source from Gitlab while still have those on the Images.lock. Chart's are annotated on CI and then wrapped.

dt charts annotate
dt wrap

• the unwrap target gitlab what relocates chart values to be GAR reader repo instead of the target (in this case) and basically only pushes images that exist on disk what skips the ones that exist on lock but not on disk.
• then based on some release process a "golden" wrap is built eventually sourcing from gitlab (the result of some unwrap like described above.. ), this wrap will be published/unwrapped to GAR Write repo (configured to have immutable tags). In this case as the source is different than the target is does the usual dt dance (although thinking that can just avoid saving any images on disk and just do a crane copy based on the Images.lock 🤔 ).
• When this wrap is published it takes over and is what's will be consumed from now on ( if that version is requested ) cutting the link with Gitlab.
• The chart values are again preserved to be the GAR Reader repo and not the GAR Writer that is the unwrap target
• The versions available and published on the GAR Writer are the ones that are available and can be consumed for non dev envs

For all the previous to work transparently It's crucial to guarantee images path preservation from Gitlab to GAR and or have controlled rewrite if desired as there are some variants and eventual some restrictions depending on the unwrap target ghcr.io | docker.io | registry.gitlab.com | ....

That's great context. And wow, you have built a thing there.

I'm approaching your PR here from a point of view of trying to keep the tool as simplest as possible. Ideally I'd like to have very simple building blocks even when that might come at the expense of having extra complexity in the client scripts. It makes this project more sustainable in the long run.

From that perspective I see that helm dt unwrap target-images-registry --push-chart-url=target-chart-registry is giving us two basic primitive arguments: one to set where images are going to be pushed, and a second one to set where the chart is going to be pushed. It can certainly be improved (e.g. kaniko for multi-registry images), but it feels effective enough.

But at the same time I have to be honest here, I'm humbled by your use case and what you are doing. So, I'm not sure if I'm missing anything obvious. Perhaps the right thing to do is as you say to abandon this one and then try to approach it with some simpler baby-step kind of change. Not sure, tbh.

Hello @mpermar

Sorry for delay getting back.

I ended with something like this

• build a wrap (from local filesystem "helm chart") that does not pull images but just contain helm chart and Images.lock. Unwrap will basically just push the chart (source registry and target registry are the same) gitlab --> gitlab

• with the previous wrap (no local images) be able to unwrap to destination registry but copy the referenced docker images as usual while source images instead of being local filesystem be a crane copy from registry source to target (source registry and target registry are not the same) .. in my case gitlab --> gar

• still have the option to "--create-offline-bundle" where all images pulled/saved locally as usual and wrapped in the wrap

same here

TODO: undo reordering

Silly comment. For consistency it would be great if you can remove this line breaks on any single paragraph.