Summary

Add direct dependencyRefs: [prometheus-operator-crds] to every base component whose Helm templates emit monitoring.coreos.com/v1 CRs (nvsentinel, k8s-ephemeral-storage-metrics) so the DAG-stratified helmfile layout survives refactors of intermediate nodes, plus a Go test that enforces the invariant.

Motivation / Context

After #926 split prometheus-operator-crds out as its own release, several components that create monitoring.coreos.com/v1 CRs (PodMonitor / ServiceMonitor / etc.) reached the CRDs only via a multi-hop transitive path:

nvsentinel → gpu-operator → kube-prometheus-stack → prometheus-operator-crds

If anyone removes the gpu-operator → kube-prometheus-stack edge in recipes/overlays/base.yaml — plausible since gpu-operator doesn't strictly need kube-prometheus-stack to install — the helm-diff race on nvsentinel's PodMonitor CR silently returns. No CI test catches it; the failure surfaces only on a fresh-cluster helmfile apply. This PR closes that gap by making the edge direct and asserting the invariant in a unit test.

Fixes: #928
Related: #914, #926

Type of Change

• Bug fix (non-breaking change that fixes an issue)

Component(s) Affected

• Recipe engine / data (pkg/recipe)

Implementation Notes

Audit method. Rendered each Helm chart in recipes/overlays/base.yaml (and registry/mixins) at its pinned version with its checked-in values file, then grepped for apiVersion: monitoring.coreos.com. Install-time emitters at our values:

Other charts whose RBAC apiGroups mention monitoring.coreos.com (gpu-operator, network-operator, k8s-nim-operator, kai-scheduler, slinky-slurm-operator) do not emit any monitoring CR in their install-time templates — the operators create those CRs at runtime once their own CRD is reconciled, which is after install ordering matters.

Test. TestMonitoringCREmittersHaveDirectPrometheusOperatorCRDsEdge in pkg/recipe/yaml_test.go enforces a direct edge (not just closure membership). Closure is too weak — the very failure the issue describes is "transitive only" silently breaking. The test body documents the helm template … | grep -c apiVersion: monitoring.coreos.com refresh recipe for chart bumps.

nvsentinel registry comment. Reworded to reflect the direct edge in base.yaml instead of the four-hop chain.

Testing

unset GITLAB_TOKEN && make qualify   # passes: tests + race + lint + e2e (22/22 chainsaw) + scan
make bom-docs                        # no diff (no chart pins / values changed)

Per-package coverage on pkg/recipe:

• Baseline (origin/main): 91.3%
• This branch: 91.3% (test-only addition)

Risk Assessment

• Low — Adds extra dependencyRefs edges to two components in base.yaml; DAG-flattening makes the extra edges no-ops while the transitive paths still exist, so install order is unchanged. The new test pins the invariant going forward.

Rollout notes: No CLI/API surface change. Generated bundles include the same components in the same install levels (verified by chainsaw cli-bundle-helmfile and cli-recipe-overlays).

Checklist

• Tests pass locally (make test with -race)
• Linter passes (make lint)
• I did not skip/disable tests to make CI green
• I added/updated tests for new functionality
• I updated docs if user-facing behavior changed (N/A — no user-visible change)
• Changes follow existing patterns in the codebase
• Commits are cryptographically signed (git commit -S)