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

Allowing for actions to be taken in failure scenarios #1376

Closed
bobcatfish opened this issue Oct 3, 2019 · 12 comments
Closed

Allowing for actions to be taken in failure scenarios #1376

bobcatfish opened this issue Oct 3, 2019 · 12 comments
Assignees
Labels
Epic Issues that should be considered as Epics (aka multiple sub-tasks, …) lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.

Comments

@bobcatfish
Copy link
Collaborator

I'm creating this as an Epic to generally cover being able to express behaviour that should occur in a Pipeline when some part of the Pipeline fails. At the moment we have Conditions in Pipelines, but afaik you can't express "if previous Task failed" as of yet b/c a Task failing will halt execution (correct me if I'm wrong @dibyom !).

And if a Task fails, any PipelineResource output actions that would have occurred will not happen (see #1149).

@bobcatfish bobcatfish added Epic Issues that should be considered as Epics (aka multiple sub-tasks, …) maybe-next-milestone For consideration when planning the next milestone labels Oct 3, 2019
@vdemeester vdemeester added this to the Pipelines 1.0/beta 🐱 milestone Nov 8, 2019
@vdemeester
Copy link
Member

Allowing for actions to be taken in failure scenarios, we should support this with Resources or without, so having a way to say "this step needs to be run even if the previous step failed".

@bobcatfish
Copy link
Collaborator Author

I think @dibyom expressed a desire to work on this :D 🤞

@vdemeester
Copy link
Member

Should #1684 and this issue be the same ? (or #1684 be one item of this epic?)

@vdemeester vdemeester removed the maybe-next-milestone For consideration when planning the next milestone label Jan 17, 2020
@bobcatfish bobcatfish removed this from the Pipelines 0.10 🐱 milestone Jan 21, 2020
@ghost ghost added this to the Pipelines 0.11 🐱 milestone Jan 21, 2020
@ghost
Copy link

ghost commented Jan 21, 2020

We should aim to get this functionality (in some form...) into 0.11, prior to the beta release going out. This is so that people can give it a try and we can work out any bad wrinkles before the beta is cut.

@dibyom
Copy link
Member

dibyom commented Jan 27, 2020

Should #1684 and this issue be the same ? (or #1684 be one item of this epic?)

#1684 is one item in this epic

@bobcatfish bobcatfish removed this from the Pipelines 0.11 🐱 milestone Feb 3, 2020
@bobcatfish
Copy link
Collaborator Author

Removed from milestone - @dibyom to create follow up issues for the work to implement the design :D

@dibyom dibyom added the priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. label Mar 18, 2020
@gpaul
Copy link
Contributor

gpaul commented May 15, 2020

I read through the comments and the design doc and I can't find a mention of how timeouts are handled.

My use case: I want to (a) collect task artifacts and (b) report status to github, using Finally tasks. One common reason for pipeline failure is timeout. In the case of a PipelineRun timing out, I would like to do both (a) and (b) once the individual non-final tasks have been stopped.

@gpaul
Copy link
Contributor

gpaul commented Jun 15, 2020

Ping?

The design doc says:

Similarly, final tasks can be configured to time out and follow the same default as standard tasks. Default Task and Pipeline Timeout is 60 minutes, documented here.

I'm still not clear: will my final task run if my pipelinerun times out after 1h?

@tekton-robot
Copy link
Collaborator

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.

@tekton-robot
Copy link
Collaborator

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 tekton-robot added the lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. label Aug 14, 2020
@tekton-robot
Copy link
Collaborator

@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.

@bobcatfish
Copy link
Collaborator Author

As mentioned in #1684: I feel like it's fair to consider this closed now that we have finally, tho there are more features to add, and to get the complete set of flexibility someone might want, i think we need to add in #2134 as well

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Epic Issues that should be considered as Epics (aka multiple sub-tasks, …) lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.
Projects
None yet
Development

No branches or pull requests

5 participants