populate chart metadata with a repoURL [hip-0018]

[sudermanjr]

What this PR does / why we need it:
Implements https://github.com/helm/community/blob/main/hips/hip-0018.md

Fixes: #4256

Signed-off-by: Luke Reed luke@lreed.net
Signed-off-by: Andy Suderman andy@suderman.dev

Special notes for your reviewer:
rebased off of, and supersedes (with permission from original author): #10369

If applicable:

• this PR contains documentation
• this PR contains unit tests
• this PR has been tested for backwards compatibility

Output when using OCI registry

 k get secret -n goldilocks sh.helm.release.v1.goldilocks.v1 -ojson |jq -r .data.release | base64 -D|base64 -D|gunzip|jq .chart.metadata
{
  "name": "goldilocks",
  "sources": [
    "https://github.com/FairwindsOps/goldilocks"
  ],
  "version": "5.1.0",
  "description": "A Helm chart for running Fairwinds Goldilocks. See https://github.com/FairwindsOps/goldilocks ",
  "keywords": [
    "goldilocks",
    "resources",
    "kubernetes"
  ],
  "maintainers": [
    {
      "name": "sudermanjr"
    },
    {
      "name": "lucasreed"
    }
  ],
  "icon": "https://raw.githubusercontent.com/FairwindsOps/charts/master/stable/goldilocks/icon.png",
  "apiVersion": "v2",
  "appVersion": "v4.1.0",
  "repoURL": "oci://us-docker.pkg.dev/fairwinds-ops/helm/goldilocks"
}

Output when installing from a locally pulled tarball or a path

▶ k get secret -n polaris2 sh.helm.release.v1.polaris2.v1 -ojson |jq -r .data.release | base64 -D|base64 -D|gunzip|jq .chart.metadata
{
  "name": "polaris",
  "version": "5.5.0",
  "description": "Validation of best practices in your Kubernetes clusters",
  "maintainers": [
    {
      "name": "rbren",
      "email": "robertb@fairwinds.com"
    }
  ],
  "icon": "https://raw.githubusercontent.com/FairwindsOps/polaris/master/pkg/dashboard/assets/favicon-32x32.png",
  "apiVersion": "v1",
  "appVersion": "7.0",
  "repoURL": "path"
}

Output when pulling from a standard helm repository

▶ k get secret -n polaris sh.helm.release.v1.polaris.v1 -ojson |jq -r .data.release | base64 -D|base64 -D|gunzip|jq .chart.metadata
{
  "name": "polaris",
  "version": "5.5.0",
  "description": "Validation of best practices in your Kubernetes clusters",
  "maintainers": [
    {
      "name": "rbren",
      "email": "robertb@fairwinds.com"
    }
  ],
  "icon": "https://raw.githubusercontent.com/FairwindsOps/polaris/master/pkg/dashboard/assets/favicon-32x32.png",
  "apiVersion": "v1",
  "appVersion": "7.0",
  "repoURL": "https://charts.fairwinds.com/stable"
}

[sabre1041]

If the chart did not originate from a repository, recommend omitting inserting path into the RepoURL field

[sudermanjr]

This was discussed during the HIP process, and ultimately decided to use a placeholder string. I'm happy to do whatever here, but wanted to make sure I followed the original HIP - https://github.com/helm/community/blob/main/hips/hip-0018.md#specification

[joejulian]

I'd almost prefer the actual path. It's a good hint if I forgot where I installed from, maybe as a file:// url?

[sudermanjr]

That could work, and I'm open to whatever y'all prefer as the maintainers. For most of the planned use-cases I have seen, the path for local charts is far less important than remote repository URLs. That being said, I can see the value of having the filepath as well.

[ksemele]

local path it's nice feature, because in big teams we can see who touched chart at last time :)

[mattfarina]

@sudermanjr Thanks for the PR. In addition to what @sabre1041 asked for, could you possibly add some simple tests for this?

[sudermanjr]

@mattfarina I addressed the other question, and I'm looking at adding some tests, but I'm struggling a bit with the right way to approach that.

The pkg/metadata changes are covered by existing tests. The tests in the cmd package seem to deal mostly with CLI output, and I don't see anything verifying chart metadata in the release. Chart_downloader seems to be a candidate for a simple test, but everything I come up with feels a bit contrived, and not valuable as an actual test.

Did you have any specific thoughts about the approach for these tests?

[ksemele]

guys, here is needed some help or not? how we can accelerate that PR?