configure a task to run after 1 or more conditional tasks #2937
Comments
prantaa
added
the
kind/feature
|
@prantaa we're designing solutions to address the issues in |
When a `Condition` fails, the guarded `Task` and its branch (dependent `Tasks`) are skipped. A `Task` is dependent on and in the branch of another `Task` as specified by ordering using `runAfter` or by resources using `Results`, `Workspaces` and `Resources`. In some use cases of `Conditions`, when a `Condition` evaluates to `False`, users need to skip the guarded `Task` only and allow dependent `Tasks` to execute. An example use case is when there’s a particular `Task` that a Pipeline wants to execute when the git branch is dev/staging/qa, but not when it’s the main/master/prod branch. Another use case is when a user wants to send out a notification whether or not a parent guarded `Task` was executed, as described in [this issue](tektoncd#2937). In this PR, we add a `continueAfterSkip` field to specify whether to terminate the whole `Task` branch, or to skip the guarded `Task` only and continue with the rest of the `Task` branch. When a `Condition` evaluates to `False`, to skip the guarded `Task` only and allow dependent `Tasks` to execute, users can pass in the `continueAfterSkip` field and set it to `true` or `yes` (case insensitive). The field defaults to `false` -- the rest of the `Task` branch is skipped by default as it was previously. I When `continueAfterSkip` is set to `True`, subsequent `Tasks` based on ordering dependencies should execute and the subsequent `Tasks` based resource dependencies will have resource validation errors.
When a `Condition` fails, the guarded `Task` and its branch (dependent `Tasks`) are skipped. A `Task` is dependent on and in the branch of another `Task` as specified by ordering using `runAfter` or by resources using `Results`, `Workspaces` and `Resources`. In some use cases of `Conditions`, when a `Condition` evaluates to `False`, users need to skip the guarded `Task` only and allow dependent `Tasks` to execute. An example use case is when there’s a particular `Task` that a Pipeline wants to execute when the git branch is dev/staging/qa, but not when it’s the main/master/prod branch. Another use case is when a user wants to send out a notification whether or not a parent guarded `Task` was executed, as described in [this issue](tektoncd#2937). In this PR, we add a `continueAfterSkip` field to specify whether to terminate the whole `Task` branch, or to skip the guarded `Task` only and continue with the rest of the `Task` branch. When a `Condition` evaluates to `False`, to skip the guarded `Task` only and allow dependent `Tasks` to execute, users can pass in the `continueAfterSkip` field and set it to `true` or `yes` (case insensitive). The field defaults to `false` -- the rest of the `Task` branch is skipped by default as it was previously. When `continueAfterSkip` is set to `True`, subsequent `Tasks` based on ordering dependencies should execute and the subsequent `Tasks` based resource dependencies will have resource validation errors.
When a `Condition` fails, the guarded `Task` and its branch (dependent `Tasks`) are skipped. A `Task` is dependent on and in the branch of another `Task` as specified by ordering using `runAfter` or by resources using `Results`, `Workspaces` and `Resources`. In some use cases of `Conditions`, when a `Condition` evaluates to `False`, users need to skip the guarded `Task` only and allow dependent `Tasks` to execute. An example use case is when there’s a particular `Task` that a Pipeline wants to execute when the git branch is dev/staging/qa, but not when it’s the main/master/prod branch. Another use case is when a user wants to send out a notification whether or not a parent guarded `Task` was executed, as described in [this issue](tektoncd#2937). In this PR, we add a `continueAfterSkip` field to specify whether to terminate the whole `Task` branch, or to skip the guarded `Task` only and continue with the rest of the `Task` branch. When a `Condition` evaluates to `False`, to skip the guarded `Task` only and allow dependent `Tasks` to execute, users can pass in the `continueAfterSkip` field and set it to `true` or `yes` (case insensitive). The field defaults to `false` -- the rest of the `Task` branch is skipped by default as it was previously. When `continueAfterSkip` is set to `True`, subsequent `Tasks` based on ordering dependencies should execute and the subsequent `Tasks` based resource dependencies will have resource validation errors.
When a `Condition` fails, the guarded `Task` and its branch (dependent `Tasks`) are skipped. A `Task` is dependent on and in the branch of another `Task` as specified by ordering using `runAfter` or by resources using `Results`, `Workspaces` and `Resources`. In some use cases of `Conditions`, when a `Condition` evaluates to `False`, users need to skip the guarded `Task` only and allow dependent `Tasks` to execute. An example use case is when there’s a particular `Task` that a Pipeline wants to execute when the git branch is dev/staging/qa, but not when it’s the main/master/prod branch. Another use case is when a user wants to send out a notification whether or not a parent guarded `Task` was executed, as described in [this issue](tektoncd#2937). In this PR, we add a `continueAfterSkip` field to specify whether to terminate the whole `Task` branch, or to skip the guarded `Task` only and continue with the rest of the `Task` branch. When a `Condition` evaluates to `False`, to skip the guarded `Task` only and allow dependent `Tasks` to execute, users can pass in the `continueAfterSkip` field and set it to `true` or `yes` (case insensitive). The field defaults to `false` -- the rest of the `Task` branch is skipped by default as it was previously. When `continueAfterSkip` is set to `True`, subsequent `Tasks` based on ordering dependencies should execute and the subsequent `Tasks` based resource dependencies will have resource validation errors.
When a `Condition` fails, the guarded `Task` and its branch (dependent `Tasks`) are skipped. A `Task` is dependent on and in the branch of another `Task` as specified by ordering using `runAfter` or by resources using `Results`, `Workspaces` and `Resources`. In some use cases of `Conditions`, when a `Condition` evaluates to `False`, users need to skip the guarded `Task` only and allow dependent `Tasks` to execute. An example use case is when there’s a particular `Task` that a Pipeline wants to execute when the git branch is dev/staging/qa, but not when it’s the main/master/prod branch. Another use case is when a user wants to send out a notification whether or not a parent guarded `Task` was executed, as described in [this issue](tektoncd#2937). In this PR, we add a `continueAfterSkip` field to specify whether to terminate the whole `Task` branch, or to skip the guarded `Task` only and continue with the rest of the `Task` branch. When a `Condition` evaluates to `False`, to skip the guarded `Task` only and allow dependent `Tasks` to execute, users can pass in the `continueAfterSkip` field and set it to `true` or `yes` (case insensitive). The field defaults to `false` -- the rest of the `Task` branch is skipped by default as it was previously. When `continueAfterSkip` is set to `True`, subsequent `Tasks` based on ordering dependencies should execute and the subsequent `Tasks` based resource dependencies will have resource validation errors.
@prantaa when the second Task ( Separately, you can explore using finally in pipelines to send out notifications. Final Tasks are guaranteed to be executed after other Tasks have completed regardless of the outcome (success/failure), which may be useful for notifications. |
|
@jerop The second task doesn't necessarily need to fail. The second task runs the tests which if the tests fail then that could be indicated in a task result variable without failing the task and further passed onto later tasks which work conditionally based on the previous task result. I don't think |
@prantaa in that case, using WhenExpressions (that support referencing task results) and whenSkipped which are coming out soon should solve your use case -- will update you when they're available |
|
Supporting task results in a finally taskis in progress, its been delayed by few weeks now, hoping to have changes in soon. |
|
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
tekton-robot
added
the
lifecycle/stale
|
@prantaa pipeline |
|
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
tekton-robot
added
lifecycle/rotten
|
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. |
Feature request
To be able to configure a task to run after 1 or more conditional tasks.
Use case
I'm trying to create the following pipeline:
Task(git clone repo) -> Task(run tests) -> Task(create git issue if tests failed) -> Task(Send out slack notification)
The create git issue task is conditional based on the results of the tests that were run previously.
I'd like to be able to run the last slack notification task after either the create git issue task completed or if it was not run due to condition (the slack message is dynamically created based on execution flow).
The text was updated successfully, but these errors were encountered: