Refactor charts definition in zarf.yaml

[Racer159]

Describe what should be investigated or refactored

It would be worth taking some time to refactor the charts definition in the zarf.yaml to enhance user understanding of the keys such as repoName and gitPath which are usually non-intuitive for users. repoName really means the name of a chart in a Helm Repo and gitPath means the path of a chart in a git repository which are not obvious to folks not familiar with Zarf.

Links to any relevant code

https://github.com/defenseunicorns/zarf/blob/f039affe91b664f601b274a5e66d29bf030ca75f/src/types/component.go#L92

Additional context

These fields have come up with questions a few times in user questions in our k8s slack.

[AustinAbro321]

propose a schema that looks like below. This is based on the examples/helm-charts within the Zarf repository. Non changed fields were taken out for brevity. Exactly one of the following field will exist for each components.charts.

- name: podinfo-repo-new
  helm:
    url: https://stefanprodan.github.io/podinfo
    name: podinfo # replaces repoName since it's only applicable for helm chart repositories
    version: 6.4.0

- name: podinfo-git-new
  git:
    url: https://stefanprodan.github.io/[email protected]
    path: charts/podinfo
    # no version field, use chart.yaml version field at that git tag

- name: podinfo-oci-new
  oci:
    url: oci://ghcr.io/stefanprodan/charts/podinfo
    version: 6.4.0

- name: podinfo-local-same
  local:
   path: chart
    # no version field, use local chart.yaml version

[AustinAbro321]

It should be noted that in the current Zarf schema the version flag is used for both OCI charts and git charts. We should leave these flags off of the git and oci sub objects and instead we should grab the information from the chart.yaml in the git repo / local directory. Git repos should specify their version with the @ syntax instead of using the version field both for the chart version and the upstream tag.

zarf/src/internal/packager/helm/repo.go

Lines 44 to 53 in 10bf746

	if isGitURL {
	// if it is a git url append chart version as if its a tag
	if refPlain == "" {
	h.chart.URL = fmt.Sprintf("%s@%s", h.chart.URL, h.chart.Version)
	}
	err = h.PackageChartFromGit(ctx, cosignKeyPath)
	if err != nil {
	return fmt.Errorf("unable to pull the chart %q from git: %w", h.chart.Name, err)
	}

zarf/src/internal/packager/helm/repo.go

Lines 156 to 163 in 10bf746

	if registry.IsOCI(h.chart.URL) {
	regClient, err = registry.NewClient(registry.ClientOptEnableCache(true))
	if err != nil {
	return fmt.Errorf("unable to create the new registry client: %w", err)
	}
	chartURL = h.chart.URL
	// Explicitly set the pull version for OCI
	pull.Version = h.chart.Version

[AustinAbro321]

Another thing we should consider is if we want to replace the @ syntax in the git repo with three additional keys, exactly one of which would be required commit, tag, and branch. The different ways to specify currently can be seen with the git-data example and it is not intuitive.

If we were to do this, we would likely also want to look at the repo syntax and allow a similar way to bring in repos. However, the two cases differ. A user will always want a specific commit in a git repo for Helm, whereas many times users will want to bring in the entire repo for gitrepos gitops cases.