Incoherencies between tkn pipeline ls and tkn task ls

[chmouel]

If we do a tkn pipeline ls we have the start, duration and status field.

while if we do a tkn task ls we only have an age :

It could be nice to homogenize this

[chmouel]

/kind feature

[danielhelfand]

/assign

[vdemeester]

This was the initial decision, to not have latest TaskRun execution on tasks. A Task can be executed in a lot of ways, in a lot of different Pipeline (or on its own), and it didn't really make sense to display the "latest" one, as.. there is no context to it.

[chmouel]

yes but we can show the satus?

[vdemeester]

yes but we can show the satus?

Which status ? We can display the status of the last run of this Task, yeah, but what is the value for this ? What if the task is ran in 50 different pipeline with complete different parameter ?

Let's take the go-build task, it is highly generic. Let's assume I have 10 pipeline that build go project in my namespace, and thus I use this task on all of them at some point (but with different parameter, as the package, and maybe some options will differ). What value does it add to display the latest run status of this ?

Also, if I have 5 pipeline running at the same time, and this task running 3 times in parallel, which one do I display ? what value does it add there too ?

It's a bit simple for Pipeline and the latest pipelinerun as a Pipeline sands on its own. The failure of a pipeline (or the success) mean something on its own. For most cases, the failure of a Task doesn't mean much outside of the Pipeline context.

[danielhelfand]

This was the initial decision, to not have latest TaskRun execution on tasks. A Task can be executed in a lot of ways, in a lot of different Pipeline (or on its own), and it didn't really make sense to display the "latest" one, as.. there is no context to it.

Can see the thought on why this was left out. I was going to make the argument that tasks are namespaced being a factor in why this makes sense (so it would be limited in terms of what it carries out), but I could see a use where multiple pipelines use the same task in a namespace. Not sure where the discussion is with referencing tasks from other namespaces, but that would further complicate this.

I think an interesting thought would be whether this applies to ClusterTasks, but It seems like there is some momentum for ClusterPipelines.

So while on the surface this looked like a good idea, I am having some second thoughts.

[chmouel]

/close

[tekton-robot]

@chmouel: Closing this issue.

In response to this:

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.