The current taskrun, pipelinerun and also the pod generate by the taskrun doesn't have running status

[zxDiscovery]

Expected Behavior

The current taskrun, pipelinerun and also the pod generate by the taskrun should show a running status for user.

Actual Behavior

root@inflict1:~/ICP/sert-test/pipeline# kubectl get pod --watch
NAME                                                      READY     STATUS     RESTARTS   AGE
demo-pipeline-run-dgg9h-pipeline-build-994rg-pod-9caa45   0/1       Init:3/4   0          1m
demo-pipeline-run-dgg9h-pipeline-build-994rg-pod-9caa45   0/1       PodInitializing   0         2m
demo-pipeline-run-dgg9h-pipeline-build-994rg-pod-9caa45   0/1       Completed   0         2m

root@inflict1:~/ICP/sert-test/pipeline# kubectl get taskrun
NAME                                           TYPE        STATUS    STARTTIME   COMPLETIONTIME
demo-pipeline-run-dgg9h-pipeline-build-994rg   Succeeded   True      2m          24s
demo-pipeline-run-dgg9h-pipeline-test-gfgxd    Succeeded   Unknown   11s         11s

I see the pod status changed from PodInitializing to Completed directly. The taskrun status always unknown. I think this maybe make user confuse if user start a long time task for his project when the status always show Init, PodInitializing or unknown.

Additional Info

knative/build#583

[bobcatfish]

The taskrun status always unknown

This is definitely confusing if you haven't seen it before! This actually comes from the kubernetes API conventions:

Condition status values may be True, False, or Unknown.

So the logic here is that Succeeded is:

• True if it has succeeded
• False if it failed
• Unknown if we don't know yet, i.e. it is running

We could add another Condition such as Running which would have it's own True, False and Unknown states, but that wouldn't actually provide more information than we already have via Succeeded and would greatly complicate interpreting the state (e.g. what would it mean for Succeded to be True and Running to be True? We'd suddenly have a number of invalid states).

So the way it currently works seems like the simplest solution that complies with the Kubernetes conventions.

Does that help?

[zxDiscovery]

@bobcatfish I see. Thanks for your reply.

[bobcatfish]

Glad that cleared things up, thanks for opening the issue @zxDiscovery !! :D