feat: integrate ManualApprovalGate as a TektonConfig child component

[jkhelil]

Background

ManualApprovalGate was introduced in commit 9c1d1b3b5 (April 2024) as a standalone CRD with types and generated artifacts, but the integration work to make it a proper TektonConfig-managed component was never completed.

As a result, ManualApprovalGate is the only active component that is:

• not referenced in TektonConfig.spec (no user-facing field)
• not present in shared/tektonconfig/ (no EnsureMAGExists / GetMAGCR helpers)
• not wired into shared/tektonconfig/tektonconfig.go (TektonConfig never creates or touches the MAG CR)

Every other component (TektonPipeline, TektonTrigger, TektonChain, TektonResult, TektonPruner, PAC) follows this pattern:

1. User configures the component via a field in TektonConfig.spec
2. TektonConfig creates the child CR with an ownerRef pointing to itself
3. TektonConfig writes platform-data-hash onto the child CR annotation whenever the cluster TLS profile changes
4. The child controller sees the annotation change and re-reconciles, picking up the new TLS env vars

Impact

Because MAG is not wired through TektonConfig, the platform-data-hash propagation chain is broken for the MAG webhook deployment. When the cluster TLS profile changes (e.g. Intermediate → Modern), all other components pick up the new TLS version and cipher suites automatically — but the manual-approval-gate-webhook deployment stays stale.

This was observed when switching to the Modern TLS profile: the MAG webhook still showed WEBHOOK_TLS_MIN_VERSION: 1.2 with 9 ciphers instead of the expected TLS 1.3 with 3 ciphers.

What is missing

1. shared/tektonconfig/manualapprovalgate/ package (~170 lines, mirrors chain/chain.go)

EnsureManualApprovalGateExists()       ← create or update the MAG CR
EnsureManualApprovalGateCRNotExists()  ← cleanup when disabled
GetManualApprovalGate()                ← fetch existing CR
CreateManualApprovalGate()             ← initial creation
UpdateManualApprovalGate()             ← update spec + annotations
GetManualApprovalGateCR()              ← build CR object with ownerRef + platform-data-hash

2. ManualApproval field in TektonConfig.spec (pkg/apis/operator/v1alpha1/tektonconfig_types.go)

// ManualApproval holds the customizable options for the manual-approval-gate component
// +optional
ManualApproval ManualApproval `json:"manualApproval,omitempty"`

3. Wire into shared/tektonconfig/tektonconfig.go (same ~10-line pattern as chain)

magCR := manualapprovalgate.GetManualApprovalGateCR(tc, r.operatorVersion)
if platformData := r.extension.GetPlatformData(); platformData != "" {
    magCR.Annotations[v1alpha1.PlatformDataHashKey] = platformData
}
if _, err := manualapprovalgate.EnsureManualApprovalGateExists(ctx, r.operatorClientSet..., magCR); err != nil {
    ...
}

4. No controller changes needed

Once TektonConfig writes platform-data-hash onto the MAG CR, the existing MAG controller event handlers (FilterController + EnqueueControllerOf on TektonInstallerSet) pick up the change automatically — exactly like TektonChain does today.

Migration concern

Currently users apply the ManualApprovalGate CR directly. Once TektonConfig manages it, the CR would be created by TektonConfig with an ownerRef. Existing standalone MAG CRs should be updated to add the ownerRef during migration (similar to how other components handle upgrades).

Related

• Original MAG introduction: 9c1d1b3b5 — "Adds Manual Approval Gate types and generated artifacts"
• TLS propagation fix: SRVKP-9613