Enhance the output of "kubectl get taskruns"

[vincent-pli]

Fix #717 #696

Changes

Any details please check the issue attached, I just want to enhance the output of "kubectl get taskrun", to make it more clear and friendly, open for discussion, thanks

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

• Includes tests (if functionality changed/added)
• Includes docs (if user facing)
• Commit messages follow commit message best practices

See the contribution guide
for more details.

Release Notes

release-note

[hrishin]

@vincent-pli thanks! for the PR 👍 .

Would you mind to update kubectl get task .. section in the https://github.com/tektoncd/pipeline/blob/master/docs/tutorial.md#task-inputs-and-outputs and maybe respective doc references? 🙂

[vdemeester]

We should go for something more like knative/build, aka https://github.com/knative/build/blob/master/config/300-build.yaml
(that's my fault on the initial PR, I should have commented that out)

[vdemeester]

@vincent-pli so I would like for us to not change anything in the status and just go with what knative/build does.

  additionalPrinterColumns:
  - name: Succeeded
    type: string
    JSONPath: ".status.conditions[?(@.type==\"Succeeded\")].status"
  - name: Reason
    type: string
    JSONPath: ".status.conditions[?(@.type==\"Succeeded\")].reason"
  - name: StartTime
    type: date
    JSONPath: .status.startTime
  - name: CompletionTime
    type: date
    JSONPath: .status.completionTime

Using kubectl to see status of the pipeline/task runs is not the end goal. A cli is in discussion, a dashoard is also on the way. We should do "just" what we can with kubectl.

[vincent-pli]

@vdemeester
Sorry to reply later, thanks for comments.
That's great if there will be a cli or dashboard to monitoring the status transformation.

For your comments, about the setting from Knative-build, that's make sense, I have tried it myself, get this:

NAME          SUCCEEDED   REASON         STARTTIME   COMPLETIONTIME
hello-build   False       BuildTimeout   10d         10d

That's looks great.
Just one thing: the "reason". Seems in pipeline, we not prepare enough explicit and meaningful expressing for it, only two: "Pending"(when pod pending) and "Building "(when pod running), even worse, at the same time, the "SUCCEDED" is "unknown", that's confuse.

I checked the code in the Knative-build, they prepare more "reasons", such as: "BuildCancelled", "BuildTimeout", "BuildValidationFailed".

So In my opinion, if we decide to leverage cli or dashboard, we just remove these information from kubectl, just like what "argo" did, or we need build a more meaningful "reason",

What do you think? :)

[vdemeester]

@vincent-pli yeah we may want to add more/meaninful Reason, but it's orthogonal for this PR though 👼. Let's do "best-effort" for this PR (with #718 (review)).

So In my opinion, if we decide to leverage cli or dashboard, we just remove these information from kubectl, just like what "argo" did, or we need build a more meaningful "reason"

We'll use the information from the API (same way kubectl does) but we won't actually depend on kubectl in anyway (or it's magic printable column thing 👼 ).

[vincent-pli]

@vdemeester
Thank for your clarification，I agree.
We could adopt the solution of Knative-build first, then prepare more meaningful "reason" later.

[vdemeester]

/ok-to-test

[vdemeester]

Given that #740 is merged, CompletionTime will now be present

/lgtm

[tekton-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vdemeester, vincent-pli

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:

• OWNERS [vdemeester]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment