How to wait for tekton pipelinRun conditions

Question

I have the following code within a gitlab pipeline which results in some kind of race condition:

kubectl apply -f pipelineRun.yaml
tkn pipelinerun logs -f pipeline-run

The tkn command immediately exits, since the pipelineRun object is not yet created. There is one very nice solution for this problem:

kubectl apply -f pipelineRun.yaml
kubectl wait --for=condition=Running --timeout=60s pipelinerun/pipeline-run
tkn pipelinerun logs -f pipeline-run

Unfortunately this is not working as expected, since Running seems to be no valid condition for a pipelineRun object. So my question is: what are the valid conditions of a pipelineRun object?

Answer 1

I didn't search too far and wide, but it looks like they only have two condition types imported from the knative.dev project?

https://github.com/tektoncd/pipeline/blob/main/vendor/knative.dev/pkg/apis/condition_types.go#L32

The link above is for the imported condition types from the pipeline source code of which it looks like Tekton only uses "Ready" and "Succeeded".

const (
    // ConditionReady specifies that the resource is ready.
    // For long-running resources.
    ConditionReady ConditionType = "Ready"
    // ConditionSucceeded specifies that the resource has finished.
    // For resource which run to completion.
    ConditionSucceeded ConditionType = "Succeeded"
)

But there may be other imports of this nature elsewhere in the project.

Answer 2

Tekton TaskRuns and PipelineRun only use a condition of type Succeeded.

Example:

conditions:
  - lastTransitionTime: "2020-05-04T02:19:14Z"
    message: "Tasks Completed: 4, Skipped: 0"
    reason: Succeeded
    status: "True"
    type: Succeeded

The different status and messages available for the Succeeded condition are available in the documentation:

• TaskRun: https://tekton.dev/docs/pipelines/taskruns/#monitoring-execution-status
• PipelineRun: https://tekton.dev/docs/pipelines/pipelineruns/#monitoring-execution-status

As a side note, there is an activity timeout available in the API. That timeout is not surfaced to the CLI options though. You could create a tkn feature request for that.