-
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
Add support for more cloud events #2677
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -155,7 +155,7 @@ point for the `Pod` in which the container images specified in your `Task` will | |
customize the `Pod` configuration specifically for that `TaskRun`. | ||
|
||
In the following example, the `Task` specifies a `volumeMount` (`my-cache`) object, also provided by the `TaskRun`, | ||
using a `PersistentVolumeClaim` volume. A specific scheduler is also configured in the `SchedulerName` field. | ||
using a `PersistentVolumeClaim` volume. A specific scheduler is also configured in the `SchedulerName` field. | ||
The `Pod` executes with regular (non-root) user permissions. | ||
|
||
```yaml | ||
|
@@ -281,7 +281,7 @@ For more information, see [`ServiceAccount`](auth.md). | |
## Monitoring execution status | ||
|
||
As your `TaskRun` executes, its `status` field accumulates information on the execution of each `Step` | ||
as well as the `TaskRun` as a whole. This information includes start and stop times, exit codes, the | ||
as well as the `TaskRun` as a whole. This information includes start and stop times, exit codes, the | ||
fully-qualified name of the container image, and the corresponding digest. | ||
|
||
**Note:** If any `Pods` have been [`OOMKilled`](https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/) | ||
|
@@ -311,6 +311,23 @@ steps: | |
startedAt: "2019-08-12T18:22:54Z" | ||
``` | ||
|
||
The following tables shows how to read the overall status of a `TaskRun`: | ||
|
||
`status`|`reason`|`completionTime` is set|Description | ||
:-------|:-------|:---------------------:|--------------: | ||
Unknown|Started|No|The TaskRun has just been picked up by the controller. | ||
Unknown|Pending|No|The TaskRun is waiting on a Pod in status Pending. | ||
Unknown|Running|No|The TaskRun has been validate and started to perform its work. | ||
Unknown|TaskRunCancelled|No|The user requested the TaskRun to be cancelled. Cancellation has not be done yet. | ||
True|Succeeded|Yes|The TaskRun completed successfully. | ||
False|Failed|Yes|The TaskRun failed because one of the steps failed. | ||
False|\[Error message\]|No|The TaskRun encountered a non-permanent error, and it's still running. It may ultimately succeed. | ||
False|\[Error message\]|Yes|The TaskRun failed with a permanent error (usually validation). | ||
afrittoli marked this conversation as resolved.
Show resolved
Hide resolved
|
||
False|TaskRunCancelled|Yes|The TaskRun was cancelled successfully. | ||
False|TaskRunTimeout|Yes|The TaskRun timed out. | ||
|
||
When a `TaskRun` changes status, [events](events.md#taskruns) are triggered accordingly. | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Similar observation as before, may be add a little more description to "The TaskRun encountered an error, but it's still running.", change it "The TaskRun encountered an error, but it's still running since waiting for other tasks or steps (need to check 🔍 ) to finish executing." 🤔 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Updated, this is again about transient errors There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. something like?
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep, failures on update are the only case. Hopefully with the genreconciler we'll see less of that |
||
### Monitoring `Steps` | ||
|
||
If multiple `Steps` are defined in the `Task` invoked by the `TaskRun`, you can monitor their execution | ||
|
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 @afrittoli for the table, its very helpful and easier to understand, few comments here:
PipelineRunCancelled
if both the rows with that reason are in a sequence.Completed
with statusTrue
in this table. I think we should include it since this table represents the overall status ofPipelineRun
.PipelineRun Status
to description or something similar.nextRprts
to finish. We can add little more to this description until we fix issue (*PipelineRun).IsDone() is incorrect #1680, "The PipelineRun encountered an error, but waiting for already running tasks to finish."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.
They are sorted by status. I could sort them by reason, that would make it more readable from a Reason pov, less readable from a status pov.... not sure which is best.
I thought status should go first as it's the primary indicator of the condition.
Nice catch, thank you
Fixed
That's not the case I was referring to here.
If any non-permanent error happens during reconcile, the reason is set to the error description, the status is set to failed, but it may be switch back to succeeded if the next reconcile cycle clears the error.
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.
Uhm, I checked this again, and there does not seem to be any transient error reported by the pipelinerun controller, so I will remove this one.
I think I will add the point you made as a general notice to the pipeline run docs.