Skip to content

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

Description

@zakisk

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 Rename OpenShiftPipelinesAsCode CRD to TektonPipelinesAsCode #3841 if both land close together

References

  • Related: Rename OpenShiftPipelinesAsCode CRD to TektonPipelinesAsCode #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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions