Support GitRepository for HelmRelease sources

[tropnikovvl]

Hello!

I use flux-local as testing for my flux setup and getting an error.

FAILED clusters/devops::apps-stack::nexus/nexus - flux_local.exceptions.HelmException: Unable to find HelmRepository for flux-system-flux-system/./helm-charts/nexus-repository-manager for HelmRelease nexus (0 other HelmRepositories in --path)

I use some HelmReleases that link not to the helm repository, but to the git repository since they are in git.

apiVersion: helm.toolkit.fluxcd.io/v2beta2
kind: HelmRelease
metadata:
  name: nexus
  namespace: nexus
spec:
  chart:
    spec:
      chart: ./helm-charts/nexus-repository-manager
      sourceRef:
        kind: GitRepository
        name: flux-system
        namespace: flux-system
  releaseName: nexus

Is it possible to expand the list of possible links for a HelmRelease?

[allenporter]

Does that work in production? The chart name isn't a path but a kubernetes resource name so it doesn't look like a chart name format I've ever seen.

[allenporter]

I see, I understand your comment now, apologies.

No that is not supported. Flux-local doesn't how to map that git repository to a local path and doesn't download for repos when run from the cli.

If this repo is local I could see it being made to work with '--sources'. Does it work to run the 'helm template' locally on a chart specified like that? I'm not familiar with git backed charts, but if it's possible to expand with that cli then there may be a way to support this.

[tropnikovvl]

https://github.com/fluxcd/flux2/discussions/2254

This is a regular helm chart that is simply located in the Git repository (GitHub). Perhaps there is some parameter that will allow me to skip a specific helm release about the operation of the application?

And another important nuance, the GitRepository object was created by flux during bootstrap, so it is not in my repository

[allenporter]

The next steps needed to support this would be:

• an example helm chart that can be included in a GitRepository for testing (only supporting the local repository)
• an example helm template command line to render the chart

I'm currently not looking into this, but if someone provided the above two things that could make it easier to get started adding support for this in flux-local.

[tropnikovvl]

https://github.com/prometheus-community/helm-charts/tree/main/charts/prometheus-blackbox-exporter

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: prometheus-community
  namespace: flux-system
spec:
  interval: 5m0s
  url: https://github.com/prometheus-community
  ref:
    branch: main

apiVersion: helm.toolkit.fluxcd.io/v2beta2
kind: HelmRelease
metadata:
  name: blackbox-exporter
  namespace: default
spec:
  chart:
    spec:
      chart: ./charts/prometheus-blackbox-exporter
      sourceRef:
        kind: GitRepository
        name: prometheus-community
        namespace: flux-system
  releaseName: blackbox-exporter

[allenporter]

Flux-local doesn't have built in support for downloading remote repositories to the local filesystem, unless it's built into helm already.

[tropnikovvl]

Okay, I have created a repository with an example. https://github.com/tropnikovvl/flux-local-test

[allenporter]

I have a prototype working of this in #638 for a repo where the helm charts are in the same GitRepository.

I found it helpful to put the local chart directory in the .krmignore file.

[tropnikovvl]

How will helm template be done in this case? Or will the test skip this helm release?

[allenporter]

How will helm template be done in this case? Or will the test skip this helm release?

In the referenced pr it runs against the local fit repo. For a remote repo it will fail since it can't download remote gitrepositories.

[tropnikovvl]

In the referenced pr it runs against the local fit repo. For a remote repo it will fail since it can't download remote gitrepositories.

I see you added cluster9, but I don't find a passed test for it. And that's why I don't yet understand how exactly it will work

[allenporter]

In the referenced pr it runs against the local fit repo. For a remote repo it will fail since it can't download remote gitrepositories.

I see you added cluster9, but I don't find a passed test for it. And that's why I don't yet understand how exactly it will work

You think I added this and it doesn't even actually do anything? :) The pr has additional tests included.

[tropnikovvl]

I mean, I didn't find tests for cluster9 in the GitHub Actions run list. But if everything works, then that’s great, thank you!

[allenporter]

I mean, I didn't find tests for cluster9 in the GitHub Actions run list.

There are tests for cluster9 in the pr, but not additionally running again in the actions.

[tropnikovvl]

Hello @allenporter !

How can I test this for myself?

[allenporter]

This has been released in version 5.1.0

[tropnikovvl]

it works for me! Many thanks

[FreekingDean]

Hm, I do find that this does not work in the github action, is that expected?

From what I can see, since the action is using very specific working directory paths, but flux-local uses the current working directory for local helm charts.

Hm, it doesn't seem like this works for diffing outside of actions either, as if you are diffing two different charts its always going to use your current working directory chart. I think it may need to change context and take "path-orig" into account when diffing repos.

Would you rather a new github issue, or stick to this one?

[allenporter]

@FreekingDean yes, expecting to work. Yes, I'd prefer opening a new github repo with detail on how to reproduce the issue. I think the way I might frame the issue is that it works when using test or the CLI for getting objects e.g. flux-local get hr but you're seeing an issue with a diff? But either way, yes open an issue. We typically reproduce issues with a local repository setup that reproduces the problem (e.g. see tests/testdata/cluster9/ which is setup with a local chart and so more details like the exact commands you're running an example of the repo are typically needed. (I don't personally use this feature myself)