Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the source repository / registry to the i #24

Open
RasmusGodske opened this issue Dec 6, 2023 · 2 comments
Open

Add the source repository / registry to the i #24

RasmusGodske opened this issue Dec 6, 2023 · 2 comments
Labels
enhancement New feature or request

Comments

@RasmusGodske
Copy link

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:

charts:
  - name: redis
    type: oci
    repository: oci://registry-1.docker.io/bitnamicharts
    version: 18.1.5

  - name: benthos
    repository: https://benthosdev.github.io/benthos-helm-chart/
    version: 0.8.0
    images_override:
    - name: benthos
      image: docker.io/jeffail/benthos:4.11.0

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.

.
└── charts/
    ├── benthos/
    │   └── 0.8.0/
    │       ├── Images.source.lock
    │       └── Images.target.lock
    └── redis/
        └── 18.1.5/
            ├── Images.source.lock
            └── Images.target.lock

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:

apiVersion: v0
kind: ImagesLock
metadata:
  generatedAt: "2023-12-06T14:51:01.632471183Z"
  generatedBy: Distribution Tooling for Helm
chart:
  name: benthos
  version: 0.8.0
  appVersion: 4.11.0
  repository: https://benthosdev.github.io/benthos-helm-chart/ <--- Like this
images:
  - name: benthos
    image: docker.io/jeffail/benthos:4.11.0
    chart: benthos
    digests:
      - digest: sha256:e2fa170d1d0c2e7bf5c89986b6e5de471fe6499f231d6f8e9c1f31c4350353b0
        arch: linux/amd64
      - digest: sha256:244e9c77b90ec18e692acf162c55060156b1d36a820d19a8606f0a98e55d4ee3
        arch: linux/arm64

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

@RasmusGodske RasmusGodske added the enhancement New feature or request label Dec 6, 2023
@mpermar
Copy link
Contributor

mpermar commented Dec 11, 2023

@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.

@RasmusGodske
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants