patterns-operator-config ConfigMap omits gitops.applicationHealthCheckEnabled, so app-of-apps sync-wave gating is silently inert #52

Summary

The patterns-operator supports gitops.applicationHealthCheckEnabled on the patterns-operator-config ConfigMap (consumed at reconcile time; default false). pattern-install is the supported install path (pattern.sh make install / rhvp.cluster_utils.install), but its ConfigMap template never renders that key — so every pattern installed through the chart gets default-off behaviour with no way to change it from pattern values.

Impact

ArgoCD 1.8 removed the built-in Application health check (argoproj/argo-cd#3781). The patterns-operator can restore it via resourceHealthChecks when the ConfigMap key is "true" — without it, an app-of-apps root Application treats child Applications as immediately healthy and applies all sync waves at once, defeating wave ordering entirely.

Observed live (validatedpatterns/coco-pattern, 15 child applications):

Reproduction

Chart at main (and tag v0.0.18), templates/pattern-operator-configmap.yaml renders exactly six keys: gitops.catalogSource, gitops.channel, gitea.chartName, gitea.helmRepoUrl, gitea.chartVersion, analytics.enabled (plus optional gitops.additionalArgoAdmins, gitops.argoRBAC, gitops.customArgoYaml).

$ helm template t . --set main.clusterGroupName=example | sed -n '/name: patterns-operator-config/,/^---/p'
data:
  gitops.catalogSource: redhat-operators
  gitops.channel: gitops-1.21
  gitea.chartName: gitea
  gitea.helmRepoUrl: https://charts.validatedpatterns.io/
  gitea.chartVersion: 0.0.*
  analytics.enabled: "true"

$ helm template t . --set main.clusterGroupName=example \
    --set main.gitops.applicationHealthCheckEnabled=true | sed -n '/name: patterns-operator-config/,/^---/p'
# byte-identical — the key never appears, so it cannot be a values problem

Operator side (v0.0.82, internal/controller/):

• patterns_operator_config.go: configKeyHealthCheck = "gitops.applicationHealthCheckEnabled", default boolFalse.
• argo.go: when the key is true, an argoproj.io/Application resource health check is appended to the ArgoCD CR spec.resourceHealthChecks.

Live confirmation: with the key written out of band, oc get argocd -A shows resourceHealthChecks containing PersistentVolumeClaim, operators.coreos.com/Subscription, and argoproj.io/Application; without it the third entry is absent.

Also missing

These operator-consumed keys are not rendered either (three appear only as comments in the template):

• gitops.customHealthChecks
• gitops.sourceNamespace
• gitops.installApprovalPlan
• gitops.csv

Proposed change

Render each key when it is set, using the same idiom as the existing additionalArgoAdmins / argoRBAC / customArgoYaml blocks, with empty-string defaults so current behaviour is unchanged:

{{- if .Values.main.gitops.applicationHealthCheckEnabled }}
  gitops.applicationHealthCheckEnabled: {{ .Values.main.gitops.applicationHealthCheckEnabled | quote }}
{{- end }}

(Quoted: the operator compares strings.EqualFold(v, "true") against ConfigMap string data.)

Workaround today

Patterns must write the ConfigMap out of band after install and before the Pattern CR's ArgoCD instance is created — which is not available on the connected make install path at all, and is a race even where it is possible. validatedpatterns/coco-pattern#165 currently carries such a workaround in its airgap bootstrap and is blocked on this issue for its connected path.

Notes

• Deliberately not proposed here: changing the operator default (separate policy question) or steering users to gitops.customArgoYaml (that key is applied via mergo.Merge(..., mergo.WithOverride), which replaces spec.resourceHealthChecks wholesale and would silently drop the operator's PVC and Subscription checks).
• Consumers pick up a released chart automatically without config changes: rhvp.cluster_utils.install renders the chart with helm template {{ pattern_install_chart }} and passes no --version, so an OCI reference resolves the highest semver tag.