unwrap/relocate option to allow values.yaml relocation to a different custom registry/repository

[machecazzon]

Is your feature request related to a problem? Please describe.

For my current use case using Google Artifact Registry (GAR)

• GAR local repository for writes
• GAR virtual repo to perform reads (from several repos including the GAR writes repo)

With this unwrap happens to go against writer repo but I would like to have values.yaml (only) relocated and pointing not to the writer repo but the reader repo so that no further "overrides" are required to consume the chart images

I have made some local modifications to have this working with one additional flag in relocate / unwrap commands e.g
--values-repository

helm dt charts relocate test-chart1 acme.com/federal --values-repository acme.com/read

helm dt unwrap kibana-10.4.8.wrap.tgz acme.com/federal --yes --values-repository acme.com/read

Then i can just consume the chart from the reader repo and chart values registry / repository are pointing to acme.com/read instead of acme.com/federal as a result of --values-repository being set to that value.

helm pull oci://acme.com/read/kibana --version 10.4.8

Is this something that could be added into the tool or any other recommendation on how to best achieve this?

Thanks

Describe the solution you'd like

Have an option to customise the relocation command for chart values and be able to set a different repo for the values.

Describe alternatives you've considered

No response

Additional context

No response

[machecazzon]

One thing I've noticed is that probably will want to modify Images.lock (and perhaps chart annotations as well) in order o that a future wrap from the "reader" repo pulls images over the reader as well.

Right now seems to work fine modifying Images.lock to the --values-repository value

[mpermar]

This is a good use case @machecazzon and reasonably common I believe. I think it makes sense what you are doing but I would approach it slightly differently. In my mind, what want dt to do is business as usual but just being able to customize the target repository for the push command.

So for example, to me it makes sense something like:

helm dt unwrap kibana-10.4.8.wrap.tgz acme.com/read --push-repository=acme.com/federal --yes

And that in essence is just the same as the tool does today but with a new parameter to customize the write repository.

The other command that would need to be changed is images push. And I'm thinking verify could need some tweak to skip verification if somehow the read repository does not have access, but I believe skipping that was already supported although I'm writing this from the top of my head.

It looks like you already have some code. That's good because we don't have much capacity right now to take requests but I think we would more than happy this change. It's a good use case.

[machecazzon]

Thanks @mpermar for the guidelines.
Yes I have some code working with my first implementation and i am good with it so far but will definitely try rework it and follow the approach you recommend and push something.

I had a look into doing it more and less that way when I first attempted to have a fix but the code path changes looked to be more evolved and not as easy as i did so I decided to turn left and not right.

Perhaps next week I am able to have something that I am happy to contribute. Thanks

[machecazzon]

@mpermar This is what i come up trying to follow your guideline. #94
When you have a chance please review and provide some feedback/concerns. Thanks