-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support using a PipelineTask in the Pipeline CRD to run other Pipelines the same way we run a Task (nest pipelines in pipelines) #2134
Comments
/kind feature |
I feel the use case is a bit unclear here. But I do have things that reminds me about this. E.g. The use-case I describe in #2505 (comment) - there I use (or "link") two On the other hand, I will have another use-case that also reminds a bit. But one fundamental difference is that I probably want to have it asynchronous. When talking about "linking" |
This feature would be really useful for us. eg. right now we have a task that can set the status on a given commit, and a task that can execute unit tests (eg. run we'd like to provide to option to use |
Thanks for the use case @madbence this looks exactly along the lines we're thinking as well - just to double check, set-status sets the status of something like a GitHub check (or similar using non-GitHub)? |
oh and i forgot to post here some relevant links:
|
@bobcatfish exactly, |
cc @mattmoor |
Tekton custom tasks would let us have this feature and more; planning to put this feature on hold until we have custom tasks and then we can decide if we want it as a top level feature or not. |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
Rotten issues close after 30d of inactivity. /close Send feedback to tektoncd/plumbing. |
@tekton-robot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/remove-lifecycle rotten |
@vdemeester: Reopened this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Couldn't this issue be done without custom tasks? We're in pain from disability to include pipelines into pipelines :) Problem is that we have to include task "run_pipeline" each time when we want to include pipeline inside pipeline. Each time such "incuded" pipeline fails, there is no easy way to find out why subpipeline failed, or what tasks it contained, etc. |
I also would really like support for running pipelines inside of pipelines. This is really useful for the case were you want some "super pipeline" that runs different variants of the same sub pipeline with different arguments (i.e. like a matrix/parameterized build from most other CI systems), provided that it can run all the sub-pipelines in parallel with different workspaces. |
Also I would like to point out that it would only really be useful if the subpipelines could be scheduled on different nodes. My (limited) understanding of tekton is that this might be difficult if the parent pipeline has to specify the workspace |
agreed. Work with workspaces is sometimes pain, double pain if super-pipeline can't create ws, so Super-pipeline runs 1) task to create ws 2) each sub-pipeline with passing it workspace as argument 3) has to finish with task that deleted ws. Also, i dont know how it could be done, but it would be better to aggregate sub-pipelines bodies into single pipelinerun. Creating separate pipeline run for each "sub"-pipeline makes it difficult to read logs of each task in each sub-pipeline(even more difficult with openshift tekton pipelines web-interface), it makes sub-pipelines execute slower(running pipelinerun isnt flash-fast itself, and it makes sometimes passing same arguments to each sub-pipeline a lot of copy-paste work. |
+1 for this feature, very helpful for reusing pipelines ! |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
/lifecycle frozen |
TEP-0056 proposing Pipelines in Pipelines is implementable - we welcome contributions in implementing it https://github.com/tektoncd/community/blob/main/teps/0056-pipelines-in-pipelines.md /help-wanted |
Happy to start working on implementing TEP-0056. /assign @EmmaMunley |
Hi, there are any updates about the implementation of the feature? |
Hi @ChrisPaul33, we have started implementing this feature. What API version are you currently using? Looking for some insight for - #7055 (comment) |
Hello @pritidesai, we are currently using v1beta1. |
Is matrix with |
Pipelines group tasks together in a workflow. It would be incredibly useful to be able to re-use that mechanism to create sub-workflows.
Pipelines and Tasks both take Params, Workspaces, and generate Results so with a little work it should be possible to use a PipelineRef in place of a TaskRef when defining a Pipeline Task. For the other aspects required to generate a "sub"-PipelineRun these could be inherited from the parent PipelineRun.
Here's a basic example to illustrate syntax...
In a nutshell, other than using pipelineRef in-place of taskRef the definitions behave the same.
The text was updated successfully, but these errors were encountered: