feat: Add support for PipelineRef in Pipeline in pipeline by danielfbm · Pull Request #9432 · tektoncd/pipeline

danielfbm · 2026-02-24T02:37:12Z

This commit adds full support for referencing a pipelien inside
another pipeline definition including using pipeline resolvers.
Single level and multi level cycle cases are all treated during
pipeline execution, failing with explicit error message

Changes

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

Adds support for using existing pipelines inside pipelines through `pipelineRef`

- This commit adds full support for referencing a pipelien inside another pipeline definition including using pipeline resolvers. - Single level and multi level cycle cases are all treated during pipeline execution, failing with explicit error message

danielfbm · 2026-02-24T03:03:37Z

/kind feature

vdemeester · 2026-02-24T06:24:49Z

cc @twoGiants

twoGiants

Thank you for your contribution @danielfbm and welcome to Tekton 😸 👍

I am very happy that you took on this important task of continuing the implementation of the pipeline in pipeline functionality. Great job 🏅

I enjoyed reviewing your PR.

Please add e2e tests once you finished the implementation.

See all my comments below and an additional question out of curiosity => how much was done by Claude Code giving the branch name danielfbm:feat/pinp-ref-claude ?

Keep up the good work and let me know if there are any questions. Write on Slack if I don't answer here for to long.

twoGiants · 2026-02-28T11:13:54Z

pkg/reconciler/pipelinerun/resources/pipelineref.go

+func GetChildPipelineFunc(ctx context.Context, k8s kubernetes.Interface, tekton clientset.Interface, requester remoteresource.Requester, pipelineRun *v1.PipelineRun, pipelineRef *v1.PipelineRef, verificationPolicies []*v1alpha1.VerificationPolicy) rprp.GetPipeline {
+	namespace := pipelineRun.Namespace
+
+	switch {


You can improve the existing code as you go. The switch/case is not needed. An if-condition is enough.

twoGiants · 2026-02-28T11:17:37Z

pkg/reconciler/pipelinerun/resources/pipelineref.go

+			}
+			resolver := resolution.NewResolver(requester, pipelineRun, string(pipelineRef.Resolver), resolverPayload)
+			return resolvePipeline(ctx, resolver, name, namespace, k8s, tekton, verificationPolicies)
+		}


This is mostly duplicated from GetPipelineFunc and can be refactored removing duplication.

twoGiants · 2026-02-28T11:22:13Z

pkg/reconciler/pipelinerun/resources/pipelineref.go

+// GetChildPipelineFunc is a factory function that will use the given PipelineRef from a PipelineTask
+// to return a valid GetPipeline function that looks up the pipeline. It handles both local cluster
+// and remote resolution.
+func GetChildPipelineFunc(ctx context.Context, k8s kubernetes.Interface, tekton clientset.Interface, requester remoteresource.Requester, pipelineRun *v1.PipelineRun, pipelineRef *v1.PipelineRef, verificationPolicies []*v1alpha1.VerificationPolicy) rprp.GetPipeline {


New public API without tests, please add unit tests.

twoGiants · 2026-02-28T11:24:30Z

pkg/reconciler/pipelinerun/pipelinerun.go

 			vp,
 		)

+		getPipelineFunc := resources.GetChildPipelineFunc(


Suggested change

getPipelineFunc := resources.GetChildPipelineFunc(

getChildPipelineFunc := resources.GetChildPipelineFunc(

twoGiants · 2026-02-28T11:27:07Z

pkg/reconciler/pipelinerun/pipelinerun.go

 					pipelineMeta.Namespace, pipelineMeta.Name, nfErr)
+			} else if errors.As(err, &pnfErr) {
+				pr.Status.MarkFailed(v1.PipelineRunReasonCouldntGetPipeline.String(),
+					"Pipeline %s/%s can't be Run; it contains Pipelines that don't exist: %s",


Suggested change

"Pipeline %s/%s can't be Run; it contains Pipelines that don't exist: %s",

"Pipeline %s/%s can't be Run; it contains child Pipelines that don't exist: %s",

twoGiants · 2026-02-28T17:22:28Z

pkg/reconciler/pipelinerun/pipelinerun.go

 	logger := logging.FromContext(ctx)
 	rpt.PipelineTask = resources.ApplyPipelineTaskContexts(rpt.PipelineTask, pr.Status, facts)

+	workspaces, _, err := c.getTaskrunWorkspaces(ctx, pr, rpt)


Why adding workspaces now? It's also a separate feature which should be implemented in a separate PR for PinP.

twoGiants · 2026-02-28T17:46:49Z

pkg/reconciler/pipelinerun/pipelinerun.go

+	}
+
+	// For PipelineRef tasks, detect and prevent pipeline-in-pipeline cycles.
+	childAnnotations := createChildResourceAnnotations(pr)


Great attempt! Appreciate the effort and that you thought about capturing cycles.

I see one core issue with this approach: it's fragile because it relies on annotations and which are mutable and comma separated pipeline names.

I see two options of doing it:

Build a PinP dependency graph by resolving all pipelineRefs recursively in the first reconcile cycle and reuse existing cycle detection logic.

Use the existing ownerReferences and the tekton.dev/pipeline label to walk up the tree up to the root in each child PipelineRun and look for reoccurring tekton.dev/pipeline labels values or for. If you find one => you have a cycle so you can return an error.

Option 1

We have a findCyclesInDependencies in dag.go#L135. Which you could make public and reuse for cycle detection. For that you'd need to implement a recursive pipelineInPipelineDependencyGraphBuilder which walks all pipelineRef tasks recursively, resolves them, and constructs map[string][]string of Pipeline→Pipeline dependencies. Then you pass the graph to findCyclesInDependencies (needs to be made public) and do that before resolvePipelineState().

Would find cycles right away and error out.

Option 2

This one can find cycles much later, depending on how deep they are nested but is easier to implement.
BUT you'd need to fix a small bug in the current implementation for it. Currently createChildResourceLabels copies all parent labels to the child, including tekton.dev/pipeline. So if the parent is running "Pipeline A" and creates a child for "Pipeline B", the child PipelineRun gets tekton.dev/pipeline: Pipeline-A -- which is wrong. The child is running Pipeline B, not A. This needs a fix. I've added a comment below.

I lean towards Option 1. Wdys @danielfbm ? And what do you say @vdemeester and @afrittoli ?

Agree with option 1, it seems a cleaner approach, even with the recursive resolving of pipelineRefs the solution seems more robust.

twoGiants · 2026-02-28T17:47:22Z

pkg/reconciler/pipelinerun/pipelinerun.go

 			Name:            childPipelineRunName,
 			Namespace:       pr.Namespace,
 			OwnerReferences: []metav1.OwnerReference{*kmeta.NewControllerRef(pr)},
 			Labels:          createChildResourceLabels(pr, rpt.PipelineTask.Name, true),


🐛 Bug 🐛
Currently createChildResourceLabels copies all parent labels to the child, including tekton.dev/pipeline. So if the parent is running "Pipeline A" and creates a child for "Pipeline B", the child PipelineRun gets tekton.dev/pipeline: Pipeline-A, which is wrong. The child is running Pipeline B, not A. This needs a fix.

twoGiants · 2026-02-28T17:49:44Z

pkg/reconciler/pipelinerun/pipelinerun.go

+
+	// For PipelineRef tasks, detect and prevent pipeline-in-pipeline cycles.
+	childAnnotations := createChildResourceAnnotations(pr)
+	if rpt.PipelineTask.PipelineRef != nil && rpt.ResolvedPipeline.PipelineName != "" {


This will be re-worked anyway but for the future => each condition needs tests covering it.

twoGiants · 2026-02-28T17:51:47Z

pkg/reconciler/pipelinerun/pipelinerun_pinp_test.go

A few more tests are missing. I am expecting:

a happy path test with one pipelineRef

a complex 2 and more levels deep nested pipelineRef tests

cycle detection tests

error tests

tekton-robot · 2026-02-28T18:00:25Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please ask for approval from twogiants after the PR has been reviewed.

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

Details

Needs approval from an approver in each of these files:

OWNERS

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

twoGiants

I found a few more things.

twoGiants · 2026-02-28T18:19:05Z

pkg/reconciler/pipelinerun/pipelinerun.go

 		},
 		Spec: v1.PipelineRunSpec{
-			PipelineSpec: rpt.PipelineTask.PipelineSpec,
+			PipelineSpec:    rpt.ResolvedPipeline.PipelineSpec,


Why also embedding in PipelineSpec for PipelineRefs? For PipelineRef you can use Spec.PipelineRef and the when the child pipelinerun will be reconciled this pipeline will be resolved. Then you don't need tekton.dev/pipeline label when searching for cycles but can use the pipeline name in Spec.PipelineRef. This would simplify Option 2 for cycle detection from above.

twoGiants · 2026-02-28T18:24:45Z

pkg/reconciler/pipelinerun/resources/pipelinerunresolution.go

 		// If the alpha feature is enabled, and the user has configured pipelineSpec or pipelineRef, it will enter here.
 		// Currently, the controller is not yet adapted, and to avoid a panic, an error message is provided here.
 		// TODO: Adjust the logic here once the feature is supported in the future.
 		return nil, fmt.Errorf("currently, Task %q does not support PipelineRef, please use PipelineSpec, TaskRef or TaskSpec instead", pipelineTask.Name)


This error needs an update.

danielfbm · 2026-03-02T02:49:46Z

Thank you for your contribution @danielfbm and welcome to Tekton 😸 👍

I am very happy that you took on this important task of continuing the implementation of the pipeline in pipeline functionality. Great job 🏅

I enjoyed reviewing your PR.

Please add e2e tests once you finished the implementation.

Keep up the good work and let me know if there are any questions. Write on Slack if I don't answer here for to long.

Thank you so much for the thoughtful review. I will do the changes accordingly.

See all my comments below and an additional question out of curiosity => how much was done by Claude Code giving the branch name danielfbm:feat/pinp-ref-claude ?

Oops, caught red-handed 😄 it did most of the coding, but I did generate some testing data and script for it to validate the code against, which helped with the edge cases (although, the code is far from optimal). I wanted to do a full review before opening this PR but I got caught in some urgent work so I though would be best to get your opinion on this, sorry if the code is not per project standards. I will follow with your change suggestions and will update here as soon as it is done.
Thanks again

twoGiants · 2026-03-02T09:09:06Z

Thank you so much for the thoughtful review. I will do the changes accordingly.

Sure thing. Looking forward to the improvements 😸 👍

Oops, caught red-handed 😄 it did most of the coding, but I did generate some testing data and script for it to validate the code against, which helped with the edge cases ...

Appreciate the honesty!

I wanted to do a full review before opening this PR ...

This was the right intention. Follow your intention for your next contribution and the re-work on this PR (and I strongly encourage you to continue to contribute). This saves maintainers valuable time.

...but I got caught in some urgent work so I though would be best to get your opinion on this ...

If you need my input on a problem you want to solve in Tekton in future contact me on Slack in the right channel or pick a way forward you think is good and open a well written and thoroughly, human reviewed PR. Review the code yourself and let Claude do a review too. You can actually ask Claude to scrutinize it's own code review and it probably will drop half of the issues it found.

...sorry if the code is not per project standards.

No, it's alright and please review any code you contribute yourself thoroughly next time before submitting (as mentioned above). I'll appreciate it.

Keep it up! 👍

github-project-automation bot added this to Tekton Community Roadmap Feb 24, 2026

github-project-automation bot moved this to Todo in Tekton Community Roadmap Feb 24, 2026

tekton-robot added the release-note-none Denotes a PR that doesnt merit a release note. label Feb 24, 2026

tekton-robot requested review from abayer and pritidesai February 24, 2026 02:37

tekton-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. release-note Denotes a PR that will be considered when it comes time to generate release notes. and removed release-note-none Denotes a PR that doesnt merit a release note. labels Feb 24, 2026

tekton-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Feb 24, 2026

twoGiants self-assigned this Feb 25, 2026

twoGiants requested changes Feb 28, 2026

View reviewed changes

	getPipelineFunc := resources.GetChildPipelineFunc(
	getChildPipelineFunc := resources.GetChildPipelineFunc(

	"Pipeline %s/%s can't be Run; it contains Pipelines that don't exist: %s",
	"Pipeline %s/%s can't be Run; it contains child Pipelines that don't exist: %s",

Conversation

danielfbm commented Feb 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

Submitter Checklist

Release Notes

Uh oh!

danielfbm commented Feb 24, 2026

Uh oh!

vdemeester commented Feb 24, 2026

Uh oh!

twoGiants left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

twoGiants Feb 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Option 1

Option 2

Uh oh!

Choose a reason for hiding this comment

Uh oh!

twoGiants Feb 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tekton-robot commented Feb 28, 2026

Uh oh!

twoGiants left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

danielfbm commented Mar 2, 2026

Uh oh!

twoGiants commented Mar 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

danielfbm commented Feb 24, 2026 •

edited

Loading

twoGiants Feb 28, 2026 •

edited

Loading

twoGiants Feb 28, 2026 •

edited

Loading

twoGiants commented Mar 2, 2026 •

edited

Loading