Improve our use of labels for navigation

[a-roberts]

Credits to @nastacio for suggesting this one - Denilson, let us know if I've missed something!

Currently, a user must know exactly what the labels are when they're about to filter, say, PipelineRuns.

What if a team doesn't know the labels they want to search on but they want to filter things at a more general level?

So for example, a test team project shouldn't need to know that everything they care about is probably going to be labelled tekton.dev/pipeline-category: test).

We could:

1. provide a list of known labels (on a per namespace level for now?)
2. Support a syntax such as pipelineruns/label=nodejs?. So, that's not exact matching, and it'll assist navigation big-time I think, especially with many resources lingering around that aren't exactly labelled in the same way.

@AlanGreene @eddycharly FYI

[eddycharly]

How about an auto complete suggestion while the user is typing ?

[nastacio]

How about an auto complete suggestion while the user is typing ?

That is positive. Another possibility is a loose search, such as "node" matching small variations, such as "Node", "node-js", "nodejs".

[a-roberts]

How about an auto complete suggestion while the user is typing ?

Yeah, that would be useful too - that combined with the "not exact matching" would be a definite improvement. I'm wondering if this will be particularly expensive so we'd only want to use known labels in the store (thinking about the performance implications on a particularly busy cluster, while still wanting to get the most up to date info)

[eddycharly]

Do we need to use the backend for that ?
I felt like it was done client side.
Looks like it's done backend side, we could maintain the labels map up to date from the informer notifications.

[a-roberts]

Do we need to use the backend for that ?
I felt like it was done client side.

Yeah, maybe you're right actually - I remember our use of labelSelector, at least at one time, being done through Go and we had all kinda trouble (to do with nameSelector as well); that may have been "legacy" code...

[eddycharly]

Another possibility is a loose search, such as "node" matching small variations, such as "Node", "node-js", "nodejs".

Not completely sure but i suspect this is not supported by kubernetes (https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors)

[a-roberts]

Another possibility is a loose search, such as "node" matching small variations, such as "Node", "node-js", "nodejs".

Not completely sure but i suspect this is not supported by kubernetes (https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors)

Yeah, so wonder if we've gotta write our own custom matcher then through Go, or Javascript through objects we've found in the store (seen already for performance reasons instead of always fetching). It would be useful to mock up a quick prototype sometime to see what it is and isn't supported, and I'm sure once @AlanGreene is back from his break we'll have more insights too

[AlanGreene]

There's also this issue to surface labels in more of the details views to help with navigation / filtering: #1181

We currently use the labelSelector query param to filter our API requests. This does not support partial matches (or variations as suggested above), so if we wanted to support this type of matching we would need to implement it ourselves, either in the back end or in the client.

In either case, we would only be operating on the loaded data, unless we were to load all resources of a given kind and deal with the volume / performance issues that brings.

There are many aspects to this that need to be considered so I think it might be worth describing it in more detail in a design doc. I'd like to make sure we properly understand the user problem so we're focusing on trying to solve the right thing here.

[tekton-robot]

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.

[tekton-robot]

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.

[tekton-robot]

@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]

/remove-lifecycle rotten
/reopen

[tekton-robot]

@AlanGreene: Reopened this issue.

In response to this:

/remove-lifecycle rotten
/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.

[AlanGreene]

One relatively simple first step we could take here is making the label tags on the ResourceDetails view clickable to navigate to a filtered list of similar resources.

A second step could revisit the typeahead / more advanced filter dropdown explored in #37 (comment) using known labels from the already loaded data in the client.

The other items, as previously discussed, require significant changes to the current APIs and rely on additional back end functionality being added to cache / batch process etc. so we can avoid or at least reduce the performance issues brought by processing a large volume of resources.

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
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 with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[AlanGreene]

This is still something we'd like to do, freezing so it doesn't get auto-closed.
/lifecycle frozen

[AlanGreene]

From Slack: https://tektoncd.slack.com/archives/CHTHGRQBC/p1611838472022800

Scott - Today at 12:54
When I'm deep-linked to a PipelineRun screen, is there a way to navigate to the Pipeline from it? I'm looking at https://dashboard.dogfooding.tekton.dev/#/namespaces/tektonci/pipelineruns/check-pr-labels-l2n98?pipelineTask=check-kind-label linked from a Github status check and ideally I'd like to get to the pipeline so I can a) figure out what it's "supposed" to be doing in the event it failed or misbehaved and b) find out information like what namespace it's in.
I've figured out I can get the namespace by looking at the URL but I'm wondering if there's any way to navigate to the associated Pipeline.

Could we use the labels for this too? How would we decide when to go to list of runs for the same pipeline / task, and when to go to the pipeline / task definition? Carbon Tag component may not be suitable for displaying the labels in this case. Needs some design exploration.

Edit: also see #1181 (comment)

[ebabani]

Hi,

When using the dashboard our team encountered similar issues with having to know the exact labels used by the tekton resources.

What we ended up doing is update the dashboard so we could set a list of labels that would be used as dropdowns for selecting those label values. This worked for us since we have a common set of labels for our resources. We also allow the filter input for any additional label filters users might want to set.

Is this something that you would be interested upstream? If so, we can send a PR.

Example of our UI:

[ebabani]

@AlanGreene let me know what you think of the above.

[AlanGreene]

Thanks for sharing @ebabani. We're considering a different approach that doesn't require specific configuration on the backend, and possibly a more condensed UI, maybe a richer search input UI based on the labels present in the resources.

See some of the previous explorations from #223, for example (not necessarily the specific design we'll pursue):

We're currently working on some updates to the list view in general and will share details of that soon. As part of that effort we're also reviewing related issues such as the search / filter experience, pagination, etc.

[ebabani]

The updated UI looks great! Looking forward to test that out.

For context, our team that will run/manage tekton is going to provide tools for teams to set up their pipelines, and the developers won't necessarily be Tekton experts or be familiar with every detail of their pipeline. Due to that, discoverability and making sure devs aren't overwhelmed in the UI is one of our goals. Hoping the UI rework makes that easier.

[nirgilboa]

@ebabani This looks great! Could you please share more details of how this was performed? Looking to make filtering by labels easier / more discoverable 🙏🏻

[ebabani]

@nirgilboa I'm no longer on that team and am not working with tekton anymore, so I don't have access to that code anymore.

One possible approach is to have the dashboard config accept a list of label names which will then be shown as dropdown options in the UI if the total list of label names is too large.

[cmorinupgrade]

Is there any progress about that feature? #1428 (comment)