Nexus not generating annotations in index.yaml file for charts

[ghost]

• What problem are you trying to solve? When loading a chart to nexus the index.yaml file is autogenerated which is great, however the index.yaml file does not include the annotations section of the Chart.yaml.

  Code autogenerated from nexus for index.yaml

  apiVersion: v1
  entries:
    test:
    - name: test
      description: A Helm chart for Kubernetes
      version: 0.1.0
      created: 2023-06-20T12:33:46.796Z
      appVersion: 1.16.0
      digest: 2fc3de50dd31205711b7218ba559065a924c25c8779f66da378287c53a6ed60b
      urls:
      - test-0.1.0.tgz
  generated: 2023-06-20T12:33:47.800Z

  Code generated from helm repo index command (this is the expected behavior)

  apiVersion: v1
  entries:
    test:
    - annotations:
        custom.config/opt1: value1
        custom.config/opt2: value2
        custom.config/opt3: value3
        custom.config/opt4: value4
      apiVersion: v2
      appVersion: 1.16.0
      created: "2023-06-20T08:29:19.627985-04:00"
      description: A Helm chart for Kubernetes
      digest: 2fc3de50dd31205711b7218ba559065a924c25c8779f66da378287c53a6ed60b
      name: test
      type: application
      urls:
      - test-0.1.0.tgz
      version: 0.1.0
  generated: "2023-06-20T08:29:19.626441-04:00"

• Do you have a workaround you are using at present? No

• What feature or behavior is this required for? We need the generated index.yaml file to provide the annotations when it is generated as we look at those values before we pull the chart.

• How could we solve this issue? (Not knowing is okay!) Enable the generation of annotations in the index.yaml file

• Tell us about your Nexus Repository deployment: what version, operating system, and database are you using? Version of Nexus is OSS 3.51.0-01, running on RHEL8.8, no database as this is OSS version

[mrprescott]

Thanks for filing this, @steporter. I'm not the team's helm expert; can you help me understand what this will help you do? We can explore adding support for this capability if there's enough demand.

[ghost]

As this is already supported by helm as a standard feature when running helm repo index, it would be good to support the same output that they generate.

There are several tools on the market that take advantage of these values. For example Rancher Server uses these values in the index.yaml file to see if only one version of a helm chart should be installed, more info can be found here.

Aside from Rancher we develop solutions for our clients that read these values before the chart is downloaded to make sure it meets the needs of the deployment. Our goal is to have Nexus built in to our solutions as the helm repo but this is a blocker for us moving forward.

[mrprescott]

@steporter Would you mind dropping me a line at my Sonatype email? I'd love to understand your requirements better.

[ghost]

Sure, I will do that.

[kyleli666]

@mrprescott I have a similar problem The apiVersion: v2 is also not generated in "entries", causing Lens or OpenLens not able to list out the charts. In @steporter 's initial issue, it is also missing.

Also someone else is looking for same help in the community https://community.sonatype.com/t/apiversion-missing-for-every-entry-in-the-helm-index-yaml/10464

[farcop]

We also need support of annotations at helm index

[olegtrautvein]

Hello. We have same problem. We are using annotations in Chart.yaml and need this info in index.yaml. Now we do manual helm repo index and moved to raw repo instead of helm repo, because nexus doesn't support annotations. Such bug request was reported before years ago: NEXUS-26120 and NEXUS-38687

[ghost]

Just wanted to see where this stands as we are still in need of this and would like to not use a git solution or other application.

[alianman]

We use Lens Desktop to install Helm charts from remote repository and after migrating to Nexus none of our charts are displayed at Lens. After some investigation we came to this issue with same problem of missing "apiVersion" field at index.yaml file. Unfortunetaly, now we will have to look for workarounds.