You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
typeTektonConfigSpecstruct {
...PipelinePipeline`json:"pipeline,omitempty"`TriggerTrigger`json:"trigger,omitempty"`ChainChain`json:"chain,omitempty"`...PlatformsPlatforms`json:"platforms,omitempty"`
}
// PipelinesAsCodeForCurrentPlatform returns the PipelinesAsCode block for the operator buildfunc (s*TektonConfigSpec) PipelinesAsCodeForCurrentPlatform() *PipelinesAsCode {
ifIsOpenShiftPlatform() {
returns.Platforms.OpenShift.PipelinesAsCode
}
returns.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
spec:
pipelinesAsCode:
enable: truesettings:
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
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
Summary
TektonConfigSpecconfiguresTektonChain,TektonTrigger, andTektonPipelineas direct top-level fields (
spec.chain,spec.trigger,spec.pipeline), butPipelinesAsCodeis nested under platform-specific blocks —spec.platforms.openshift.pipelinesAsCodeandspec.platforms.kubernetes.pipelinesAsCode— with the value duplicated perplatform and resolved at runtime via a helper method. This issue proposes
promoting it to a single top-level
spec.pipelinesAsCodefield, consistentwith every other component.
Background
PipelinesAsCode was historically an OpenShift-branded project
(
openshift-pipelines/pipelines-as-code), which is presumably why itsoperator config was placed under the OpenShift-specific
platformsblock inthe first place, later duplicated under
platforms.kuberneteswhenKubernetes support was added. The upstream project has since moved to
tektoncd/pipelines-as-code(see #3841, which tracks renaming theOpenShiftPipelinesAsCodeCRD kind toTektonPipelinesAsCodefor the samereason). #3841 explicitly scopes out this structural question:
This issue tracks that follow-up separately, since it's an independent (if
related) change to
TektonConfigSpecshape rather than the CRD kind name.Current State
pkg/apis/operator/v1alpha1/tektonconfig_types.go:pkg/apis/operator/v1alpha1/openshift_platform.go/kubernetes_platform.goeach carry their own
PipelinesAsCode *PipelinesAsCodefield — two copies ofthe 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 activepkg/reconciler/shared/tektonconfig/pipelinesascode/pipelinesascode.go(
createOPAC/updateOPAC) — reads viaconfig.Spec.PipelinesAsCodeForCurrentPlatform()pkg/reconciler/openshift/tektonconfig/extension.go(lines 215, 288) andpkg/reconciler/kubernetes/tektonconfig/extension.go(lines 62, 82) —same helper
pkg/reconciler/shared/tektonconfig/upgrade/pre_upgrade.go(line 181) —reads
Platforms.OpenShift.PipelinesAsCodedirectlyThe user-facing YAML also has to route through the platform block even
though PAC itself already runs identically on both platforms:
(
docs/TektonConfig.md, lines 124-146)Proposed Change
Add
PipelinesAsCode PipelinesAsCodeas a top-level field onTektonConfigSpec, alongsidePipeline,Trigger, andChain:Resulting YAML:
This removes the need for
PipelinesAsCodeForCurrentPlatform()and theper-platform defaulting dance in
tektonconfig_defaults.goentirely — onefield, one validation path, one reconciler read.
Scope of Changes
API types
PipelinesAsCodetoTektonConfigSpecinpkg/apis/operator/v1alpha1/tektonconfig_types.goPipelinesAsCodefromOpenShift(openshift_platform.go) andKubernetes(kubernetes_platform.go) platform structsPipelinesAsCodeForCurrentPlatform()and update every call sitelisted above to read
config.Spec.PipelinesAsCodedirectlyDefaults / validation
tektonconfig_defaults.go— drop the Kubernetes→OpenShift copylogic and the two separate default blocks in favor of one
tektonconfig_validation.go— drop theIsOpenShiftPlatform()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 newtop-level field
pkg/reconciler/shared/tektonconfig/upgrade/pre_upgrade.go— this is anexisting upgrade-path file; it may need a companion migration step that
copies a populated
platforms.{openshift,kubernetes}.pipelinesAsCodeforward into the new
spec.pipelinesAsCodefield for existing clusters(see Migration below)
Code generation
./hack/update-codegen.shandmake generate-crds/make sync-helm-crdsafter the type change; commit regenerated CRDsunder
config/base/generated-crds/and the Helm chart templatesDocs
docs/TektonConfig.md— update theplatforms.{openshift,kubernetes}YAML examples (lines 124-146) and the
OpenShiftPipelinesAsCodesection(line ~556) to reference
spec.pipelinesAsCodeconfig/crs/referencing PAC settings underplatformsTests
Platforms.{OpenShift,Kubernetes}.PipelinesAsCodeTektonConfigCR with PAC settings underplatformsMigration / Compatibility
This is a breaking API change for any
TektonConfigCR that currentlysets
spec.platforms.openshift.pipelinesAsCodeorspec.platforms.kubernetes.pipelinesAsCode.Suggested approach, consistent with the deprecation-window strategy
discussed in #3841: keep the old
platforms.*.pipelinesAsCodefieldsaccepted (deprecated, not removed) for one or two minor releases, with
SetDefaults/pre_upgrade.gocopying a populated old field forward intothe new
spec.pipelinesAsCodeif the new field is unset. Remove the oldfields 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.pipelinesAsCodeis a top-level field onTektonConfig,consistent with
spec.chain/spec.trigger/spec.pipelinePlatforms.OpenShift.PipelinesAsCodeandPlatforms.Kubernetes.PipelinesAsCodeare removed (or deprecated perthe migration plan) and
PipelinesAsCodeForCurrentPlatform()isdeleted
make lintandmake testpass with zero failures./hack/update-codegen.shandmake sync-helm-crdshave been re-runand generated files are committed
docs/TektonConfig.mdand any CR samples updated to the new fieldlocation
coordinated with Rename
OpenShiftPipelinesAsCodeCRD toTektonPipelinesAsCode#3841 if both land close togetherReferences
OpenShiftPipelinesAsCodeCRD toTektonPipelinesAsCode#3841 (renameOpenShiftPipelinesAsCodeCRD kind toTektonPipelinesAsCode) — explicitly scopes out this structural questionpkg/apis/operator/v1alpha1/tektonconfig_types.go,pkg/apis/operator/v1alpha1/openshift_platform.go,pkg/apis/operator/v1alpha1/kubernetes_platform.goChain/Trigger/Pipelinefields inpkg/apis/operator/v1alpha1/tektonconfig_types.go