ResourceSet flux-operator dependsOn HelmRelease CRD fails

[rmoreas]

What happened?

When managing the Flux Operator itself using a ResourceSet, it is not possible to declare a dependency on the HelmRelease CRD.

The ResourceSet for "flux-operator" contains a HelmRelease resource and declares a dependency on the corresponding CRD (helmreleases.helm.toolkit.fluxcd.io):

apiVersion: fluxcd.controlplane.io/v1
kind: ResourceSet
metadata:
  name: flux-operator
  namespace: flux-system
spec:
  serviceAccountName: flux-operator
  dependsOn:
    - apiVersion: apiextensions.k8s.io/v1
      kind: CustomResourceDefinition
      name: helmreleases.helm.toolkit.fluxcd.io
  resources:
    - apiVersion: source.toolkit.fluxcd.io/v1
      kind: OCIRepository
      metadata:
        name: flux-operator
        namespace: flux-system
      spec:
        interval: 1h
        url: oci://ghcr.io/controlplaneio-fluxcd/charts/flux-operator
        ref:
          semver: '*'
        verify:
          provider: cosign
          matchOIDCIdentity:
          - issuer: ^https://token\.actions\.githubusercontent\.com$
            subject: ^https://github\.com/controlplaneio-fluxcd/charts/\.github/workflows/release\.yml@refs/tags/v\d+\.\d+\.\d+$
    - apiVersion: helm.toolkit.fluxcd.io/v2
      kind: HelmRelease
      metadata:
        name: flux-operator
        namespace: flux-system
      spec:
        interval: 1h
        releaseName: flux-operator
        serviceAccountName: flux-operator
        chartRef:
          kind: OCIRepository
          name: flux-operator
        values:
          multitenancy:
            enabled: true
            defaultServiceAccount: default
          reporting:
            interval: 5m

flate reports the following error:

✗  CustomResourceDefinition  flux-system/helmreleases.helm.toolkit.fluxcd.io  not found
         required by flux-system/flux-operator

  ✗ 1 failed · 1 blocked

Expected Behavior

In a Flux Operator setup, it is common for Flux CRDs not to be present in Git repositories because they are installed dynamically by the FluxInstance. Therefore, a dependency on a CRD that will be installed by the operator itself appears to be a valid use case and Flate should not block tests with a "not found" error.

Steps to reproduce

The d1-fleet repo can be used as example.

git clone https://github.com/controlplaneio-fluxcd/d1-fleet.git
cd d1-fleet
flate build all --allow-missing-secrets -p clusters/prod-eu

This gives:

✗  ConfigMap  backend/flux-runtime-info  not found
         required by backend/flux-backend
  ✗  ConfigMap  frontend/flux-runtime-info  not found
         required by frontend/flux-frontend
  ✗  CustomResourceDefinition  flux-system/helmreleases.helm.toolkit.fluxcd.io  not found
         required by flux-system/flux-operator

  ✗ 3 failed · 3 blocked

The missing flux-runtime-info ConfigMaps can be ignored on this repos.

Relevant logs or output

Version

v0.4.12

[buroa]

Makes sense - a CRD the operator installs at runtime won't be in Git, so a dependsOn on it shouldn't fail the run.

Under the hood the dependsOn entry becomes a dependency edge, and a CRD absent from the store classifies as "not found" at drain. Plan: add an opt-in (something like --allow-missing-crds) that lets absent CRD dependencies classify as satisfied, mirroring how --allow-missing-secrets already works for source/valuesFrom secrets. Default behavior stays unchanged.