Skip to content
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

Be able to use when expressions in finally Tasks #3438

Closed
bobcatfish opened this issue Oct 22, 2020 · 6 comments
Closed

Be able to use when expressions in finally Tasks #3438

bobcatfish opened this issue Oct 22, 2020 · 6 comments
Assignees
Labels
area/roadmap Issues that are part of the project (or organization) roadmap (usually an epic) kind/feature Categorizes issue or PR as related to a new feature.

Comments

@bobcatfish
Copy link
Collaborator

bobcatfish commented Oct 22, 2020

Feature request

To be able to combine when expressions with task execution status in finally tasks to be able to express when you want actions to happen in the case of the failure of another Task (without having to modify the Task to be aware of the success/failure case, e.g. use Tasks straight from the catalog).

Use case

From Andrew Johnson on slack:

I'd like to conditionally run a set of steps (can be tasks as well) if a task in the main pipeline fails - So an OnFailure (of a specific task) as opposed to Finally.

For example, let's say we want to post to slack (using this slack catalog task when a certain Task in the Pipeline fails:

  tasks:
    - name: do-things
      taskRef:
        name: do-things
  finally:
    - name: alert-slack
       when:
          - input: "$(context.pipelineRun.Tasks.do-things.status)"
            operator: in
            values: ["failed"]
      taskRef:
        name: send-to-channel-slack
      params:
        - name: channel-id
          value: foo-bar
        ...

Andrew also describes how this has to be worked around when we do not have this feature:

The way I'm currently orchestrating this is by writing a failed status to a workspace file before the task and then removing the failed status after the task. If, when we get to finally, the status is still failed then the steps (or tasks) should run. This currently requires custom tasks that check for the file first.

This means that in order to get this functionality:

  1. The executing Task has to be aware of the need to track its status in a workspace
  2. The finally Task has to be aware of the meaning of the values written to the workspace

(1) and (2) would prevent a user from being able to use catalog Tasks as is for this use case

@bobcatfish bobcatfish added the kind/feature Categorizes issue or PR as related to a new feature. label Oct 22, 2020
@bobcatfish
Copy link
Collaborator Author

@jerop @pritidesai might be relevant to your interests! feel free to close if there is already an issue tracking this

@jerop
Copy link
Member

jerop commented Oct 22, 2020

@jerop @pritidesai might be relevant to your interests! feel free to close if there is already an issue tracking this

this is something we've been discussing as next steps after execution status and task results are supported in finally tasks but don't have an issue to track afaik, thanks for opening this...will assign myself

/assign

@tekton-robot
Copy link
Collaborator

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
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 with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

@tekton-robot tekton-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jan 31, 2021
@jerop
Copy link
Member

jerop commented Feb 1, 2021

actively working on this issue, wrote the WhenExpressions in Finally Tasks TEP and opened PR with the implementation of the TEP in #3738

/remove-lifecycle stale

@tekton-robot tekton-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Feb 1, 2021
@bobcatfish bobcatfish added the area/roadmap Issues that are part of the project (or organization) roadmap (usually an epic) label Feb 24, 2021
@bobcatfish
Copy link
Collaborator Author

hey @jerop this is done, right?

@jerop
Copy link
Member

jerop commented Feb 24, 2021

hey @jerop this is done, right?

yes, it's available in release v0.21:

@jerop jerop closed this as completed Feb 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/roadmap Issues that are part of the project (or organization) roadmap (usually an epic) kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

No branches or pull requests

3 participants