A Task can be configured to not commence execution until a condition, such as a particular value being present in the TaskRun's metadata, is true.
Tasks always run to completion or failure
This would enable building features like manual approval or automated quality gates in higher-level applications utilizing Build Pipeline, rather than requiring that any specific "wait until X is true before executing this Task" functionality be built directly into the CRDs.
...this is my first attempt at creating an issue here, so feel free to rewrite as needed. =)
Thanks for writing this up @abayer !
Would you see yourself expressing this at the level of the Pipeline or the Task itself? (I'm thinking Pipeline?)
Hmm. Good question. As part of the Pipeline reference to the Task does feel logical when I think about it. The Task could be used in multiple Pipelines that may not always all want the constraint. Good catch, thanks!
@abayer do you see this as being a subtask of https://github.com/knative/build-pipeline/issues/27 or do you think this issue addresses separate concerns?
@bobcatfish Feels different to me - #27 is "should this Task execute at all" while this is "when should this Task execute". But I could be wrong.
@bobcatfish Feels different to me - #27 is "should this Task execute at all" while this is "_when_ should this Task execute". But I could be wrong.
Makes sense @abayer ! I also updated the description here with some requirements that @demobox shared with me, i.e. that pausing and resuming is really about async execution in general
I also updated the description here with some requirements that @demobox shared with me
Thanks, @bobcatfish! Happy to elaborate on those if useful
Happy to elaborate on those if useful
Always @demobox :D :D :D
hey @abayer @bobcatfish @demobox
Would you see yourself expressing this at the level of the Pipeline or the Task itself? (I'm thinking Pipeline?)
Considering this would it be fine to declare "wait until condition" at pipeline task (just like RunAfter) level rather task definition?
Could you please shed some light on this?
Hey, just want to check if we would see this getting implemented anytime soon.
Is this going to allow a user interaction like in Jenkins Input Step?
For example, I would like to run "helmfile diff" task and then manually approve the continuation of the pipeline. The next task would probably be "helmfile sync", but it would be nice to manually review the diffs before approving it.
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
Send feedback to tektoncd/plumbing.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Send feedback to tektoncd/plumbing.
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
/close
Send feedback to tektoncd/plumbing.
@tekton-robot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity.
Reopen the issue with/reopen.
Mark the issue as fresh with/remove-lifecycle rotten./close
Send feedback to tektoncd/plumbing.
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.
This is in our roadmap
/lifecycle frozen
I believe that https://github.com/tektoncd/pipeline/issues/215 will solve this so I'm inclined to close it in favor of #215
Most helpful comment
Hey, just want to check if we would see this getting implemented anytime soon.