tektoncd
Display TaskRun and PipelineRun labels
Expected behavior
When looking at a TaskRun and PipelineRun I should be able to see labels associated to it. This will greatly help filtering similar taskruns and pipelineruns. One cool feature would be to associate a link to each label redirects to a page with the filtered list based on the key and value of that label.
Actual behavior
Labels are not displayed at all for taskruns and pipelineruns.
Environment
-
Kubernetes Platform: GKE
-
Tekton Pipelines version: v0.10.1
-
Tekton Triggers version: v0.3.1
-
Tekton Dashboard version: v0.5.1 --
Additional Info
Agreed this would be very useful. We already have the ability to filter all resource views by label either using the filter input displayed at the top of the page or via query param on the URL (both of these approaches are connected, updating one will update the other to match) e.g. ?labelSelector=tekton.dev/pipeline=demo-pipeline, expanding where we take advantage of this existing functionality makes a lot of sense.
Related: https://github.com/tektoncd/dashboard/issues/762
We're moving towards a new standard layout for all resource types, which includes displaying labels among other metadata. We have begun implementing this on the triggers pages (EventListener, TriggerBinding, etc.). So it would just be a matter of making the labels clickable and linking to this filtered view using the existing mechanism.
The PipelineRun (https://github.com/tektoncd/dashboard/issues/675) and TaskRun (https://github.com/tektoncd/dashboard/issues/776) designs need a little more attention to incorporate this standard layout, as well as additional status information in the run headers.
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
/close
Send feedback to tektoncd/plumbing.
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
Send feedback to tektoncd/plumbing.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Send feedback to tektoncd/plumbing.
@tekton-robot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen. Mark the issue as fresh with/remove-lifecycle rotten./close
Send feedback to tektoncd/plumbing.
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.
@AlanGreene: Reopened this issue.
In response to this:
/remove-lifecycle stale /lifecycle frozen /reopen
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.
If adopting the ResourceDetails component for the common layout already used by most of the other resource types we still need to consider third-party consumers of the @tektoncd/dashboard-components, in particular the PipelineRun component which incorporate the header. In the ResourceDetails view this header would be separate from the TaskTree and other elements of the page.
There may be a transition period where the component needs to support both, allowing consumers time to migrate. Alternatively we could take a similar approach already used within the header to allow consumers to easily inject custom content into defined locations.
An extension of this idea: it might be nice to also link to the Task / Pipeline referenced by label (or a filtered view of Task / Pipeline). At the moment if I'm deep-linked to a PipelineRun page I'm not able to easily navigate to the Pipeline that the PR is built from. Ideally I'd like to get to it so that I can refer back to what the PipelineRun is "supposed" to do in the event that it either failed or is exhibiting some funky behaviour.
