You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
My personal usecase is a mirroring tool, that mirrors helm charts to an internal OCI registry. So fare this is done using custom bash script, which takes a yaml file that looks like the following:
This bash script will obviously wrap and unwrap the charts, to the target repository. However on top of that, I've decided to store the Images.lock files. Both the original Images.lock file (The source) and the relocated Images.lock file (The target).
This is stored within a repository, to help keep track of the mirroed helm charts.
The problem is that the generated Images.lock file, currently does not contain the souce of where the helm chart were pulled from. Which would be nice to locate it in the future.
Describe the solution you'd like
My suggestion is simply adding the repository to within the Images.lock like this:
However a different name might be prefered, as one might not consider a OCI-registry a "repository". Can't up with a better term myself at this moment.
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered:
@RasmusGodske really thanks for taking the time to propose this enhancement. I don't think the lock is the place to put the source repository as it feels like adding distribution information to the lock itself. That can easily end up in weird multi-registry redistributions A->B and then B->C situations, where the lock will depend on the Helm chart OCI registry.
I think for what you want, it just makes sense to add that information on the Chart.yaml itself. Maybe on the sources field, maybe just under metadata. Would that help your use case?
I'm open to see if someone else using the tool finds that piece of information important in the lock though.
You might be right about that. I'm simply interested in what images is present in my target registry, as well as where the originates from. I don't want to store the actual charts with the images within the repository.
For now I'm just gonna add repository to the Images.lock as I suggested, until I found a better solution. However I understand why you don't want that here.
Is your feature request related to a problem? Please describe.
My personal usecase is a mirroring tool, that mirrors helm charts to an internal OCI registry. So fare this is done using custom bash script, which takes a yaml file that looks like the following:
This bash script will obviously
wrap
andunwrap
the charts, to the target repository. However on top of that, I've decided to store theImages.lock
files. Both the originalImages.lock
file (The source) and the relocatedImages.lock
file (The target).This is stored within a repository, to help keep track of the mirroed helm charts.
The problem is that the generated
Images.lock
file, currently does not contain the souce of where the helm chart were pulled from. Which would be nice to locate it in the future.Describe the solution you'd like
My suggestion is simply adding the
repository
to within theImages.lock
like this:However a different name might be prefered, as one might not consider a OCI-registry a "repository". Can't up with a better term myself at this moment.
Describe alternatives you've considered
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: