-
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
access taskRun reason
in addition to status
in finally task
#8127
Conversation
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
dc75ed8
to
53a1706
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
/retest |
Does it need to be documented that users can use |
53a1706
to
cf182a8
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
/retest |
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.
Thanks for this! It looks good to me, I have a few NITs, but I'd be happy to merge this and resolve them in a separate PR if you prefer
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: afrittoli, chitrangpatel The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
A finally task can access both the reason and status of a pipelineTask from the tasks section. When onError is set to either continue or stopAndFail and the task fails, the status is set to the same value Failed, making it indistinguishable whether the failure was allowed or not. However, when onError is set to continue, the reason is assigned FailureIgnored. This additional information can be used to identify that the checks failed, but the failure can be ignored. The syntax is $(tasks.<pipelineTask>.reason) Signed-off-by: Priti Desai <pdesai@us.ibm.com>
cf182a8
to
b9176af
Compare
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
Thanks @chitrangpatel and @afrittoli for the reviews! I have addressed all the comments. Currently, the CI is failing due to the rate limit. |
/retest |
/lgtm |
/retest |
2 similar comments
/retest |
/retest |
Once again, we are running into the same rate limit issue :(
|
Because we autoscale the cluster nodes up and down, every time we run jobs on a new node it will pull images. |
/test pull-tekton-pipeline-integration-tests |
/test pull-tekton-pipeline-go-coverage-df |
@afrittoli: The specified target(s) for
The following commands are available to trigger optional jobs:
Use 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. |
The following is the coverage report on the affected files.
|
Changes
A
finally
task can access both thereason
andstatus
of apipelineTask
from the tasks section.When
onError
is set to eithercontinue
orstopAndFail
and the task fails, the status is set to the same valueFailed
, making it indistinguishable whether the failure was allowed or not. However, whenonError
is set to continue, the reason is assignedFailureIgnored
. This additional information can be used to identify that the checks failed, but the failure can be ignored.The syntax is
$(tasks.<pipelineTask>.reason)
/kind feature
Fixes # #8110
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
/kind <type>
. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tepRelease Notes