Promote PipelinesAsCode from spec.platforms.* to a top-level TektonConfigSpec field

Inizia con le definizioni dei campi in pkg/apis/operator/v1alpha1/tektonconfig_types.go, openshift_platform.go e kubernetes_platform.go, quindi segui i valori predefiniti, la validazione, i reconciler, la gestione degli aggiornamenti, i test, la documentazione e i CRD generati elencati nell'issue. Decidi e documenta la migrazione di compatibilità, aggiorna tutti i riferimenti e gli esempi interessati, rigenera il codice e i CRD e verifica con make lint e make test.

Summary

TektonConfigSpec configures TektonChain, TektonTrigger, and TektonPipeline
as direct top-level fields (spec.chain, spec.trigger, spec.pipeline), but
PipelinesAsCode is nested under platform-specific blocks —
spec.platforms.openshift.pipelinesAsCode and
spec.platforms.kubernetes.pipelinesAsCode — with the value duplicated per
platform and resolved at runtime via a helper method. This issue proposes
promoting it to a single top-level spec.pipelinesAsCode field, consistent
with every other component.

Background

PipelinesAsCode was historically an OpenShift-branded project
(openshift-pipelines/pipelines-as-code), which is presumably why its
operator config was placed under the OpenShift-specific platforms block in
the first place, later duplicated under platforms.kubernetes when
Kubernetes support was added. The upstream project has since moved to
tektoncd/pipelines-as-code (see #3841, which tracks renaming the
OpenShiftPipelinesAsCode CRD kind to TektonPipelinesAsCode for the same
reason). #3841 explicitly scopes out this structural question:

Update TektonConfigSpec references that wire PAC installation (field
names in Platforms.OpenShift.PipelinesAsCode /
Platforms.Kubernetes.PipelinesAsCode may stay as-is since they are not
the CRD kind)

This issue tracks that follow-up separately, since it's an independent (if
related) change to TektonConfigSpec shape rather than the CRD kind name.

Current State

pkg/apis/operator/v1alpha1/tektonconfig_types.go:

type TektonConfigSpec struct {
    ...
    Pipeline  Pipeline  `json:"pipeline,omitempty"`
    Trigger   Trigger   `json:"trigger,omitempty"`
    Chain     Chain     `json:"chain,omitempty"`
    ...
    Platforms Platforms `json:"platforms,omitempty"`
}

// PipelinesAsCodeForCurrentPlatform returns the PipelinesAsCode block for the operator build
func (s *TektonConfigSpec) PipelinesAsCodeForCurrentPlatform() *PipelinesAsCode {
    if IsOpenShiftPlatform() {
        return s.Platforms.OpenShift.PipelinesAsCode
    }
    return s.Platforms.Kubernetes.PipelinesAsCode
}

pkg/apis/operator/v1alpha1/openshift_platform.go / kubernetes_platform.go
each carry their own PipelinesAsCode *PipelinesAsCode field — two copies of
the same struct, one per platform, only one of which is ever active per
build.

Every call site has to route through PipelinesAsCodeForCurrentPlatform()
or duplicate the IsOpenShiftPlatform() branch directly:

• pkg/apis/operator/v1alpha1/tektonconfig_defaults.go (lines ~42-109) —
  copies the Kubernetes value into the OpenShift field, nils out the other,
  and applies PAC defaults per-platform
• pkg/apis/operator/v1alpha1/tektonconfig_validation.go (lines 78-81) —
  branches on IsOpenShiftPlatform() to validate whichever field is active
• pkg/reconciler/shared/tektonconfig/pipelinesascode/pipelinesascode.go
  (createOPAC/updateOPAC) — reads via
  config.Spec.PipelinesAsCodeForCurrentPlatform()
• pkg/reconciler/openshift/tektonconfig/extension.go (lines 215, 288) and
  pkg/reconciler/kubernetes/tektonconfig/extension.go (lines 62, 82) —
  same helper
• pkg/reconciler/shared/tektonconfig/upgrade/pre_upgrade.go (line 181) —
  reads Platforms.OpenShift.PipelinesAsCode directly

The user-facing YAML also has to route through the platform block even
though PAC itself already runs identically on both platforms:

spec:
  platforms:
    openshift:   # or `kubernetes:` on Kubernetes clusters
      pipelinesAsCode:
        enable: true
        settings:
          application-name: Pipelines as Code CI
          ...

(docs/TektonConfig.md, lines 124-146)

Proposed Change

Add PipelinesAsCode PipelinesAsCode as a top-level field on
TektonConfigSpec, alongside Pipeline, Trigger, and Chain:

type TektonConfigSpec struct {
    ...
    Pipeline        Pipeline        `json:"pipeline,omitempty"`
    Trigger         Trigger         `json:"trigger,omitempty"`
    Chain           Chain           `json:"chain,omitempty"`
    PipelinesAsCode PipelinesAsCode `json:"pipelinesAsCode,omitempty"`
    ...
}

Resulting YAML:

spec:
  pipelinesAsCode:
    enable: true
    settings:
      application-name: Pipelines as Code CI
      ...

This removes the need for PipelinesAsCodeForCurrentPlatform() and the
per-platform defaulting dance in tektonconfig_defaults.go entirely — one
field, one validation path, one reconciler read.

Scope of Changes

API types

• Add PipelinesAsCode to TektonConfigSpec in
  pkg/apis/operator/v1alpha1/tektonconfig_types.go
• Remove PipelinesAsCode from OpenShift (openshift_platform.go) and
  Kubernetes (kubernetes_platform.go) platform structs
• Remove PipelinesAsCodeForCurrentPlatform() and update every call site
  listed above to read config.Spec.PipelinesAsCode directly

Defaults / validation

• Simplify tektonconfig_defaults.go — drop the Kubernetes→OpenShift copy
  logic and the two separate default blocks in favor of one
• Simplify tektonconfig_validation.go — drop the IsOpenShiftPlatform()
  branch at lines 78-81

Reconcilers

• pkg/reconciler/shared/tektonconfig/pipelinesascode/pipelinesascode.go,
  pkg/reconciler/openshift/tektonconfig/extension.go,
  pkg/reconciler/kubernetes/tektonconfig/extension.go — read the new
  top-level field
• pkg/reconciler/shared/tektonconfig/upgrade/pre_upgrade.go — this is an
  existing upgrade-path file; it may need a companion migration step that
  copies a populated platforms.{openshift,kubernetes}.pipelinesAsCode
  forward into the new spec.pipelinesAsCode field for existing clusters
  (see Migration below)

Code generation

• Re-run ./hack/update-codegen.sh and make generate-crds /
  make sync-helm-crds after the type change; commit regenerated CRDs
  under config/base/generated-crds/ and the Helm chart templates

Docs

• docs/TektonConfig.md — update the platforms.{openshift,kubernetes}
  YAML examples (lines 124-146) and the OpenShiftPipelinesAsCode section
  (line ~556) to reference spec.pipelinesAsCode
• CR samples under config/crs/ referencing PAC settings under platforms

Tests

• Unit tests for defaults/validation currently asserting on
  Platforms.{OpenShift,Kubernetes}.PipelinesAsCode
• E2E tests that build a TektonConfig CR with PAC settings under
  platforms

Migration / Compatibility

This is a breaking API change for any TektonConfig CR that currently
sets spec.platforms.openshift.pipelinesAsCode or
spec.platforms.kubernetes.pipelinesAsCode.

Suggested approach, consistent with the deprecation-window strategy
discussed in #3841: keep the old platforms.*.pipelinesAsCode fields
accepted (deprecated, not removed) for one or two minor releases, with
SetDefaults/pre_upgrade.go copying a populated old field forward into
the new spec.pipelinesAsCode if the new field is unset. Remove the old
fields in a later release once the deprecation window closes. Whichever
approach is chosen should land in the same release cycle as #3841 given the
overlapping migration/upgrade-guide work, and both should be documented
together in the release notes.

Acceptance Criteria

• spec.pipelinesAsCode is a top-level field on TektonConfig,
  consistent with spec.chain / spec.trigger / spec.pipeline
• Platforms.OpenShift.PipelinesAsCode and
  Platforms.Kubernetes.PipelinesAsCode are removed (or deprecated per
  the migration plan) and PipelinesAsCodeForCurrentPlatform() is
  deleted
• make lint and make test pass with zero failures
• ./hack/update-codegen.sh and make sync-helm-crds have been re-run
  and generated files are committed
• docs/TektonConfig.md and any CR samples updated to the new field
  location
• Upgrade path documented (migration guide or release note), and
  coordinated with #3841 if both land close together

References

• Related: #3841 (rename OpenShiftPipelinesAsCode CRD kind to
  TektonPipelinesAsCode) — explicitly scopes out this structural question
• Current field definitions: pkg/apis/operator/v1alpha1/tektonconfig_types.go,
  pkg/apis/operator/v1alpha1/openshift_platform.go,
  pkg/apis/operator/v1alpha1/kubernetes_platform.go
• Naming convention reference: Chain/Trigger/Pipeline fields in
  pkg/apis/operator/v1alpha1/tektonconfig_types.go
• Pipelines-as-Code upstream repo: https://github.com/tektoncd/pipelines-as-code