-
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
Update TaskRun Step States After Cancellation or Timeout #3088
Update TaskRun Step States After Cancellation or Timeout #3088
Conversation
/kind feature |
The following is the coverage report on the affected files.
|
2e6630e
to
7190933
Compare
The following is the coverage report on the affected files.
|
7190933
to
35d5a6d
Compare
The following is the coverage report on the affected files.
|
35d5a6d
to
717ea47
Compare
The following is the coverage report on the affected files.
|
717ea47
to
8197294
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
/cc @bobcatfish @pritidesai @afrittoli
8197294
to
8c8b3d0
Compare
The following is the coverage report on the affected files.
|
@danielhelfand the changes looks good and fixes the step status for a When a task times out as part of a Pipeline, these changes does update the pipeline run status with an appropriate step status but
I tried on my local cluster for this sample pipeline run:
And here is the
|
8c8b3d0
to
541625e
Compare
The following is the coverage report on the affected files.
|
@pritidesai Looking into this a bit further, I think the status needs some time before it updates. I noticed the same issue you pointed out, but it eventually does update the statuses correctly:
|
Looking further into the issue, this looks like a case where the TaskRun is actually still Running and is not timed out despite the PipelineRun timeout. This is occurring in v0.15.2 with this same PipelineRun, so it might be related to issues around timeouts with pipelines. But I do think this is not related to the changes here. |
541625e
to
f47169f
Compare
The following is the coverage report on the affected files.
|
Sounds good thanks @danielhelfand. @bobcatfish was looking into |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: pritidesai 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 |
f47169f
to
1018eaa
Compare
The following is the coverage report on the affected files.
|
/lgtm |
Pipelines now updates the status of steps for cancelled or timed out TaskRuns, see tektoncd/pipeline#3088 Update the styles and labels to display these as cancelled rather than failed (which was the fallback for unknown status/reason combos)
Pipelines now updates the status of steps for cancelled or timed out TaskRuns, see tektoncd/pipeline#3088 Update the styles and labels to display these as cancelled rather than failed (which was the fallback for unknown status/reason combos)
Pipelines now updates the status of steps for cancelled or timed out TaskRuns, see tektoncd/pipeline#3088 Update the styles and labels to display these as cancelled rather than failed (which was the fallback for unknown status/reason combos)
Closes tektoncd/cli#1095
Changes
In the event a TaskRun is timed out or cancelled, pipelines currently leaves the state of steps as Running or PodInitializing depending on how far the TaskRun has proceeded. This pull request adds a feature to update the status of steps to TaskRunTimeout or TaskRunCancelled. This will help with properly reporting step statuses through
tkn
to end users to avoid confusion.The current approach only updates a step status if the step state is Running or Waiting. If a step has already completed, the status will be preserved.
I am open to suggestions on a different status that can be returned for steps other than the TaskRun reason.
Submitter Checklist
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