Update of Included Git Repository doesn't trigger Reconciliation of HelmChart

[ketbla]

Describe the bug

I'm trying to setup a GitOps framework where I will be using 3 Git Repositories:

• 1 for values files
• 1 for company Helm Charts
• 1 for app Helm Charts

In The end I want to combine each Chart Repository with Values files repository, so then I could generate HelmChart with combined valuesFiles. Everything seems to be working however I found a bug with HelmChart reconciliation when using included GitRepositories.

I've set HelmChart reconcilationStrategy to Revision, however when using included GitRepositories, when the included GitRepository is refreshed (in this case Values files) it doesn't generate new Revision for the upstream GitRepository (Helm Chart), therefore HelmChart never triggers an update.

If I update HelmChart repository, then changes are picked up.

Workarround: In order to workarround, I have to suspend and resume HelmChart, then it picks up new changes.

Steps to reproduce

1. Create GitRepository with values files.
2. Create GitRepository with HelmChart with included.
3. Create HelmRelease which uses HelmChart GitRepository to generate chart based on Revision and install it.
4. Update Values repository.
5. HelmChart never updates itself because HelmCharts still points to the same Revision.

Expected behavior

1. Create GitRepository with values files.
2. Create GitRepository with HelmChart with included.
3. Create HelmRelease which uses HelmChart GitRepository to generate chart based on Revision and install it.
4. Update Values repository.
5. Upstream GitRepository should change Revision.
6. HelmChart detects changes and updates itself.

Maybe new reconciliation strategy could be added for HelmChart in addition to chart version and revision, we could use Digest or something else that would change when the Included GitRepository is changed?

Screenshots and recordings

No response

OS / Distro

N/A

Flux version

v2.3.0

Flux check

❯ flux check
► checking prerequisites
✗ flux 2.3.0 <2.5.0 (new CLI version is available, please upgrade)
✔ Kubernetes 1.31.3 >=1.28.0-0
► checking version in cluster
✔ distribution: flux-v2.3.0
✔ bootstrapped: true
► checking controllers
✔ helm-controller: deployment ready
► ghcr.io/fluxcd/helm-controller:v1.0.1
✔ kustomize-controller: deployment ready
► ghcr.io/fluxcd/kustomize-controller:v1.3.0
✔ notification-controller: deployment ready
► ghcr.io/fluxcd/notification-controller:v1.3.0
✔ source-controller: deployment ready
► ghcr.io/fluxcd/source-controller:v1.3.0
► checking crds
✔ alerts.notification.toolkit.fluxcd.io/v1beta3
✔ buckets.source.toolkit.fluxcd.io/v1beta2
✔ gitrepositories.source.toolkit.fluxcd.io/v1
✔ helmcharts.source.toolkit.fluxcd.io/v1
✔ helmreleases.helm.toolkit.fluxcd.io/v2
✔ helmrepositories.source.toolkit.fluxcd.io/v1
✔ kustomizations.kustomize.toolkit.fluxcd.io/v1
✔ ocirepositories.source.toolkit.fluxcd.io/v1beta2
✔ providers.notification.toolkit.fluxcd.io/v1beta3
✔ receivers.notification.toolkit.fluxcd.io/v1
✔ all checks passed

Git provider

GitLab

Container Registry provider

No response

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct

[jmcenteeIV]

Can you post an example of one of your HelmRelease files and potentially more context on how you are applying the values files? I assume they are being managed by a Kustomization and being applied to the cluster as a ConfigMap that is then defined in the valuesFrom of the HelmRelease? IF this is the case do you see that the updates to the values are being applied to the ConfigMap/Secret in the cluster?

[ketbla]

No this is a bit different case, so to give more context, let's assume I have this structure.
Repository with charts and their main configuration

.
├── charts
│   └── nginx
└── values
   └── nginx
       └── values.yaml

Repository for configuration only to release based on region, environment, etc...

.
├── westeurope
│   └── nginx
│      └── values.yaml
└── uat
   └── nginx
       └── values.yaml

Then I create GitRepository resource referencing first repository and including the second one:

---
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: values
spec:
  interval: 5m0s
  url: https://repository-2/
  ref:
    branch: master
---
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: charts
spec:
  interval: 5m0s
  url: https://repository-1/
  ref:
    branch: master
  include:
    - repository:
        name: values
      toPath: extra-values

Once I have this structure, i can create HelmChart resource packaging multiple values files:

---
apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmChart
metadata:
  name: podinfo
  namespace: default
spec:
  interval: 5m0s
  chart: ./charts/nginx
  reconcileStrategy: Revision
  sourceRef:
    kind: GitRepository
    name: charts
    ignoreMissingValuesFiles: true
    valuesFiles:
        - values/nginx/values.yaml
        - extra-values/westeurope/nginx/values.yaml
        - extra-values/uat/nginx/values.yaml

With this aproach, I can package HelmChart with different values and install it. However HelmChart currently supports only 2 reconcileStrategy options "Revision|Version". The 2nd one, requires to bump chart version to force HelmChart to reconcile, the first one Reconciles on every commit.

However if I do commit to the values repository, which is included, it does not create new revision for upstream, only digest changes.

So this does not work as expected because included git repositories are supposed to refresh upstream, and they do refresh upstream gitrepository, however they do not refresh upstream helm charts. I end up in situation where I need to either do a commit to the charts repository. Or suspend/resume chart resource.

[jmcenteeIV]

@ketbla Thanks so much for adding the additional context. I apologize because, as can be seen in my initial question, I was ignorant to the HelmChart CRD and how it differed from HelmRelease. Ill spend some more time pondering this issue and playing around with HelmCharts and see if I can be more useful in a follow-up reply.

[ketbla]

Thanks a lot. This is quite critical for us to have a properly scalable platform for different teams, therefore we want to use "include" functionality. And I think somehow changes on Included GitRepository should trigger new HelmChart.

Option 1)
Git Repository Revision combines all included GitRepository commits, so even if included GitRepository changes, it forces new Revision on upstream resource and forces new HelmChart.

Option 2)
HelmChart resource could include new parameter - "reconcileStrategy: Digest". Because as far as I noticed from my tests, when included GitRepository changes, Upstream repository "Digest" also changes.

I think first option might be more difficult to implement as it changes logic and perhaps doesn't make sense if Revision is calculated instead of showing commit number.

Second option should be relatively easy, just to add additional option next to existing configuration parameter.