Summary

Honor overrides: {enabled: false} end-to-end so a component disabled in a recipe/overlay (e.g. cert-manager on OKE, where the CSP provides its own) is excluded from both the recipe's deploymentOrder and the generated bundle — across all deployers, including helmfile. Re-enabling a recipe-disabled component at bundle time is explicitly disallowed.

Notes for Reviewers

• Broader than it first looked. The recipe layer and the helmfile bundle layer use different topological-sort code paths, so fixing only the recipe layer left the helmfile deployer still failing with a false circular-dependency error on a disabled depended-upon component. The fix covers both: skip disabled components in the recipe-layer sort, and prune dangling dependency edges in the bundler before the helmfile deployer recomputes levels.
• Re-enabling a recipe-disabled component is disallowed (--set <component>:enabled=true now errors). It would complicate the fix, and — more importantly — re-enabling at bundle time creates drift between the recipe and what is actually deployed. I'm not convinced we should allow it at all; open to discussion.

Motivation / Context

The recipe and bundle layers invoke different topological-sort helpers, and neither honored a disabled component:

• TopologicalSort() (recipe resolution) and ComponentRefsTopologicalLevels() (helmfile bundle generation) iterated over every ComponentRef with no IsEnabled() check, so a disabled component still appeared in deploymentOrder.
• The bundler removes disabled components from ComponentRefs but left dependents' DependencyRefs dangling, so the helmfile deployer's ComponentRefsTopologicalLevels call saw an undeclared edge and failed with a false circular-dependency error.

This blocked the clean way to drop the AICR-bundled cert-manager for OKE (OKE infra provides its own; two cert-managers on one cluster conflict), part of the P0 vanilla-OKE recipe work.

Fixes: #1464
Related: N/A

Type of Change

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

Component(s) Affected

• Recipe engine / data (pkg/recipe)
• Bundlers (pkg/bundler)
• Docs/examples (docs/)

Implementation Notes

Recipe layer (pkg/recipe/metadata.go). TopologicalSort() and ComponentRefsTopologicalLevels() now skip disabled components and treat an edge pointing at a declared-but-disabled component as already satisfied (assumed provided externally), so dependents such as gpu-operator order correctly instead of tripping the cycle guard. Edges to undeclared components are still counted, preserving missing-dependency detection (guarded by an existing test). Shared logic factored into componentSets() / edgeSatisfiedExternally().

Bundler (pkg/bundler/bundler.go). After filtering disabled components out of ComponentRefs, prune dependents' DependencyRefs that point at the removed components, so the helmfile deployer's level computation no longer sees a dangling edge. DeploymentOrder continues to be filtered from the recipe's authored order (not recomputed), preserving existing ordering.

Re-enable disallowed. --set <component>:enabled=true on a component the recipe disabled is now rejected with ErrCodeInvalidRequest. The author disables a component because the platform already provides it, so re-enabling would install a conflicting second copy and has no authored deployment order. --set <component>:enabled=false still disables a component the recipe leaves on.

Testing

go test ./pkg/recipe/... ./pkg/bundler/...
golangci-lint run -c .golangci.yaml ./pkg/recipe/... ./pkg/bundler/...

• pkg/recipe and pkg/bundler suites pass; lint reports 0 issues.
• Recipe topo tests gained disabled-leaf and disabled-dependency cases; the bundler --set enabled precedence test now asserts re-enabling a recipe-disabled component errors.
• Pre-existing, unrelated pkg/bundler/attestation failure (TestFetchAmbientOIDCToken) reproduces on clean origin/main — environmental (ambient OIDC), outside this change.

Manual end-to-end verification

Built aicr from this branch and temporarily disabled cert-manager (has dependents gpu-operator + nvsentinel) and k8s-ephemeral-storage-metrics (a leaf) in the h100-eks-ubuntu-training overlay via overrides: {enabled: false}. The overlay edit was for verification only and is not part of this PR.

1. aicr recipe — deploymentOrder 14 → 12, both disabled components gone; gpu-operator + nvsentinel still ordered correctly (no false cycle); both disabled components remain in componentRefs with enabled: false.
2. aicr bundle (default helm deployer) — exactly 12 numbered component dirs; no disabled component anywhere.
3. aicr bundle --deployer helmfile (the previously-broken path) — succeeds, 12 dirs, no dangling cert-manager edge / false circular-dependency error.
4. aicr bundle --set certmanager:enabled=true — rejected with [INVALID_REQUEST] component "cert-manager" is disabled by the recipe and cannot be re-enabled.

Risk Assessment

• Low — Behavior is unchanged when no component is disabled (recipe deploymentOrder still filtered from the authored order; bundler pruning is a no-op without dangling edges). Additive tests; easy to revert.

Rollout notes: N/A — backwards compatible. The only behavior change for existing users is that --set <component>:enabled=true on a recipe-disabled component now errors instead of silently re-including it (previously unsupported in practice — the re-enabled component was mis-ordered).

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
• Changes follow existing patterns in the codebase
• Commits are cryptographically signed (git commit -S)