-
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
consuming task results in finally #3242
consuming task results in finally #3242
Conversation
/kind feature |
The following is the coverage report on the affected files.
|
0c4a922
to
c3478c2
Compare
The following is the coverage report on the affected files.
|
c3478c2
to
83e8c63
Compare
The following is the coverage report on the affected files.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
excited to see results supported in finally tasks!
we can look into extending it to support guarding execution of final tasks based on task results using when expressions
@@ -305,6 +311,18 @@ func (state PipelineRunState) GetTaskRunsStatus(pr *v1beta1.PipelineRun) map[str | |||
}) | |||
} | |||
} | |||
// Maintain a TaskRun Object in pr.Status for a finally task which could not resolve task results |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it might be worthwhile to explore adding these final tasks to skipped tasks (or another separate section for final tasks with invalid results) -- instead of creating a TaskRun object for a final task that wasn't executed
related discussion: #3139
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes thats an alternative, another alternative could be: Tekton controller replacing such unresolved param with type default which is empty string for string type params. Let that final task execute expecting that the task author has implemented sanitization on such input params. @bobcatfish thoughts?
83e8c63
to
ab888e7
Compare
The following is the coverage report on the affected files.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
ab888e7
to
7caa8fe
Compare
The following is the coverage report on the affected files.
|
Happy to see this PR. Moves us closer to being able to conditionally execute finally tasks. |
7caa8fe
to
f87896f
Compare
The following is the coverage report on the affected files.
|
Please review whenever you can @tektoncd/core-maintainers, would like to get this in 0.17 🙏 |
Small suggestion, doesn't have to be a blocker on this PR, but it would be great to see an example yaml added to examples/v1beta1/pipelineruns for this too if possible. /approve |
thanks @sbwsg, thats a great suggestion. Putting it on a brief hold until I add and end-to-end example. |
91d31b2
to
09a92fd
Compare
Hey @bobcatfish I think I have responded to most of the comments. I have tried to explain both of these: (1) Need for a separate Let me know if you would want to see any more changes in this PR including any refactoring. I will be happy to change this PR or create separate PR if possible. Also, simplifying the check if a finally should be skipped only by looking at the referenced task status is not reliable. Even after a referenced task exits with success, it is possible that referenced result might not be initialized. These simplification would work after we fix this issue #3497 and adding this kind of validation. |
The following is the coverage report on the affected files.
|
one more ping 🛎 |
Hey @vdemeester we discussed this in the planning meeting this morning. I think we put this PR on hold so that it can be redesigned (skip instead of creating an object reference for a finally task referring to missing task results). Can we cancel the hold since the design is updated? We have moved this PR to next milestone 0.21 for now. |
👍🏼 /hold cancel |
@pritidesai needs a rebase 🙏🏼 |
Final tasks can be configured to consume Results of PipelineTasks from tasks section
09a92fd
to
242155d
Compare
The following is the coverage report on the affected files.
|
sorry @vdemeester for delay, done 👍 |
/lgtm |
It was implemented in tektoncd/pipeline#3242
It was implemented in tektoncd/pipeline#3242
It was implemented in tektoncd/pipeline#3242
It was implemented in tektoncd/pipeline#3242
It was implemented in tektoncd/pipeline#3242
Changes
Final tasks can be configured to consume
results
ofPipelineTasks
fromtasks
section.Based on the TEP, a final task failing to resolve task results is added to the list of
skippedTasks
and warning is recorded in controller logs.Implements TEP #0004
Closes #2557
Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
See the contribution guide for more details.
Double check this list of stuff that's easy to miss:
cmd
dir, please updatethe release Task to build and release this image.
Reviewer Notes
If API changes are included, additive changes must be approved by at least two OWNERS and backwards incompatible changes must be approved by more than 50% of the OWNERS, and they must first be added in a backwards compatible way.
Release Notes