FluxCD helm release fails when using ocirepo resource as chart reference

[a1994sc]

Environment

App version: v0.47.0
Kubernetes distro being used: kind, rke2

Steps to reproduce

1. Create files in the Additional Context section
2. Package those files and deploy to a zarf cluster with fluxcd installed

Expected result

The helm-controller installs the 0.13.0 version of the external-secrets helm-release

Actual Result

Helm throws a version mismatch error because of the -zarf- and crc32 checksum

Visual Proof (screenshots, videos, text, etc)

artifact revision 0.13.0-zarf-3677108702 does not match chart version 0.13.0

Resolution

I think that zarf should allow the ability to remove the crc32 checksum from resources when a certain annotation is provided:
zarf.dev/remove-checksum

Additional Context

kustomization.yml

---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: external-secrets
resources:
  - namespace.yml
  - helm-release.yml
  - oci-repo.yml
configMapGenerator:
  - name: hr-values-external-secrets
    files:
      - values.yaml
    options:
      disableNameSuffixHash: true

helm-release.yml

---
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: external-secrets
spec:
  interval: 1m
  chartRef:
    kind: OCIRepository
    name: ghcr-io-external-secrets
  valuesFrom:
    - kind: ConfigMap
      name: hr-values-external-secrets
      optional: false

namespace.yml

---
apiVersion: v1
kind: Namespace
metadata:
  name: external-secrets

oci-repo.yml

---
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: OCIRepository
metadata:
  name: ghcr-io-external-secrets
spec:
  interval: 12h
  layerSelector:
    mediaType: "application/vnd.cncf.helm.chart.content.v1.tar+gzip"
    operation: copy
  url: oci://ghcr.io/external-secrets/charts/external-secrets
  ref:
    tag: 0.13.0

values.yaml

---
# yaml-language-server: $schema=https://raw.githubusercontent.com/external-secrets/external-secrets/refs/heads/main/deploy/charts/external-secrets/values.schema.json
leaderElect: true
replicaCount: 2
image:
  repository: ghcr.io/external-secrets/external-secrets
  flavour: ubi-boringssl
webhook:
  replicaCount: 2
  image:
    repository: ghcr.io/external-secrets/external-secrets
    flavour: ubi-boringssl
certController:
  replicaCount: 2
  image:
    repository: ghcr.io/external-secrets/external-secrets
    flavour: ubi-boringssl

zarf.yaml

---
# yaml-language-server: $schema=https://raw.githubusercontent.com/zarf-dev/zarf/main/zarf.schema.json
kind: ZarfPackageConfig
metadata:
  name: external-secrets
  # renovate: datasource=docker depName=ghcr.io/external-secrets/charts/external-secrets
  version: 0.13.0
components:
  - name: main
    manifests:
      - name: external-secrets
        namespace: external-secrets # This is where the helm secret/state is stored.
        kustomizations:
          - ./.
    images:
      - ghcr.io/external-secrets/external-secrets:v0.13.0-ubi-boringssl
      - ghcr.io/external-secrets/charts/external-secrets:0.13.0
  - name: images
    required: false
    charts:
      - name: external-secrets
        namespace: external-secrets
        url: oci://ghcr.io/external-secrets/charts/external-secrets
        version: 0.13.0
        valuesFiles:
          - values.yaml

[AustinAbro321]

Thanks for the detailed issue with repro steps!

The easiest fix in the meantime would be to use a digest in your OCI repo instead of a tag, this will prevent the agent from doing any mutation.

  ref:
    digest: d1700931bc7a4de82790ea7e275eca861259bc71b4bca53f52cfa35e3ef8800d

Still, the fact that though OCI repo mutation doesn't work with Helm chart objects is definitely a bug and should be fixed. I'm not sure we'll want to solve the way #3436 does as generally we want to encourage sha's and keep the agent simple. Perhaps we should disable the CRC32 hash all together for the OCI repo and live with collisions as the trade off. Will need to put more thought into it

[a1994sc]

So this does seem to be a problem that only really relates to helm, as using a fluxcd artifact works fine with the crc32 mutation.

I was thinking that a possible way to address the issue would be to check registry manifest, but that requires reaching out to the registry and what not... so using the annotations was the "simplest" MVP (minimal viable product).

And I understanding not waiting to do the direction I did in the PR, I will leave it open for now