Nr. 3 - [TEP-0056]: Implement Pipelines-in-Pipelines reconciliation.

[twoGiants]

Important

Pull request number 3.
The numbering Nr. 3 - [TEP-0056] means the PRs must be merged in order. They build on each other.

Changes

[TEP-0056]: Third PR of Pipelines-in-Pipelines feature implementation.

Child PipelineRuns (PinP) are created by the PipelineRun reconciler, equal to the TaskRun/CustomRun implementations.

An event handler for child PipelineRuns is registered in controller entrypoint. This will trigger the reconciliation loop when child PipelineRuns change their state.

Extend resolvePipelineState with getter for child PipelineRuns using lister and extend runNextSchedulableTask with a condition check for a PipelineTask which is a Pipeline and implement the creation of a new PipelineRun from the resolved pipeline state and pipeline facts.

Setting the ChildReferences was extended for child PipelineRuns.

Rename label/annotation factory.

The unit/e2e test framework was refactored and extended to prepare for future tests. The test setup is a parent pipeline with one or more embedded child/grandchild pipelines using the PipelineSpec (alpha) field. It follows the given-when-then test flow arrangement.

The pipeline manifests yaml definitions use variables for every field which is validated. Multiple helper functions were created equal to reconciliation unit tests for TaskRuns/CustomRuns.

Test data factory functions were put in the testing package in the factory.go file.

The unit tests validates:

• the status and condition of the parent PipelineRuns which should trigger the creation of the child PipelineRuns,
• the actual created child/grandchild PipelineRuns if they have the correct metadata i.e. name, owner reference, etc. and the embedded pipelines from the PipelineSpec fields in the pipeline tasks of the parent pipeline.

Similar checks are performed in TestReconcile for TaskRun and in TestReconcile_V1Beta1CustomTask for CustomTasks.

The e2e tests validate:

• parent PipelineRun creation,
• child PipelineRun creation,
• successful finish of all resources,
• correct label and annotation propagation,
• amount of events published.

Similar checks are performed in
TestPipelineRun|TestPipelineRunStatusSpec|... for TaskRun and in TestCustomTask for CustomTask.

Issues #8760, #7166.

Release notes will be added with the last PR which will make this feature functional for users.

/kind feature

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

• Has Docs if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps
• Has Tests included if any functionality added or changed
• pre-commit Passed
• Follows the commit message standard
• Meets the Tekton contributor standards (including functionality, content, code)
• Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
• Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of good release notes.
• Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes

A Pipeline can now execute embedded Pipelines (Pipelines-in-Pipelines) using the `PipelineSpec` field under `tasks`. Refer to the TEP-0056 for more details.

[tekton-robot]

The following Tekton test failed:

Test name	Commit	Details	Required	Rerun command
check-pr-has-kind-label	86cc7e7	link	true	/test check-pr-has-kind-label

[tekton-robot]

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/reconciler/testing/factory.go	Do not exist	0.0%

[waveywaves]

/kind feature

[vdemeester]

@twoGiants this now can be rebased 👼🏼

[vdemeester]

2025-10-30T13:34:00.0427657Z examples_test.go:128: exit status 1 Output: Error from server (BadRequest): error when creating "STDIN": admission webhook "validation.webhook.pipeline.tekton.dev" denied the request: validation failed: feature flag enable-cel-in-whenexpression should be set to true to use CEL: '$(params.path)' == 'README.md' in WhenExpression: spec.pipelineSpec.tasks[0].when[0]

[vdemeester]

There is really something fishy with the example tests and feature-flags

[vdemeester]

2025-10-30T13:34:03.1437169Z Error from server (BadRequest): error when creating "STDIN": admission webhook "validation.webhook.pipeline.tekton.dev" denied the request: validation failed: feature flag enable-param-enum should be set to true to use Enum: spec.params[message]
2025-10-30T13:34:03.1441196Z Error from server (BadRequest): error when creating "STDIN": admission webhook "validation.webhook.pipeline.tekton.dev" denied the request: validation failed: feature flag enable-param-enum should be set to true to use Enum: spec.finally.params[message], spec.tasks.params[message]

[vdemeester]

/approve
/lgtm

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vdemeester

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [vdemeester]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment