Improve the discoverability of Runners for a project
Problem to solve
As described here: gitlab-design#664 (closed).
It is difficult to know which runners are available to you at the project level, given the non-ideal format it is in within CI/CD settings. There can be 100s of shared runners listed, which in turn hides the available group runners for the project, and therefore makes it difficult to understand which runners are available and which types are available. Also, we are using multiple columns to break up project, shared and group runners. It is not easy to read or navigate through the view because of the setup. It is confusing and doesn't aid the comprehension of the concepts (Shared vs Specific Runners).
Intended users
Personas are described at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/
JTBD this issue relates to
When I have to address a specific CI build use case or CI platform administrative requirement, I want to configure the CI build software application to ensure that the CI/CD pipeline jobs can run successfully for the specified project types.
User story
As a developer, I want to be able to discover what runners are available to my project, so I can ensure that my jobs will run properly.
Existing research/issues that connects with this
- There are extreme performance issues within the project runners section today because we load all available runners to the project at once and do not use pagination. It is extremely difficult to navigate through the list of available runners considering we list them out in overlapping columns with no pagination.
- Previous scorecard evaluations has noted that the layout of the project runners section is not usable.
Currently, the Runners settings section is too hard to parse and follow. The information could be organized better and have a better vertical rhythm. Also, the general information architecture of the page could be improved by relying on better navigation flow controls like tabs.
From https://gitlab.com/gitlab-org/ux-research/-/issues/2391+:
Project runners view is difficult to use
The admin/group views UI are significantly more usable than the project for the following reasons:
- Summary stats are necessary for the project view to get a quick overview.
- It’s difficult to find the runners that you want to manage.
- Specific runners that are available to be shared (include the “enable for project” button next to them) create a huge amount of noise in the UI. It is difficult to locate the relevant runners when they are listed.
- Tons of runners are created using the helm chart installation and it makes it difficult to find which ones are actually online and running jobs.
I think in the, in the project we, it'll be what is more important is being able to segregate these different type of runners. And that's, you know, and rather than, because if you look at some of our projects where we have, you know, they are further down in the hierarchy, and if you look at runners, then sometimes there are like hundreds of runners available to the, to that project.
which is very common that our users complain, is that when they try to mix the mix, the runners like centrally managed runners with their own runner setup, they always complain that because since they do not have the access to see the group level or instance level runners, they complain that on project level they have limited visibility of the workload shared across these runners. So even on group level, that is a, that is not available. So if I look at a runner on group level, I can't see what jobs are running on that pipelines are running. And same goes for on the project view. So it's Gotcha. Yeah. And, and, and, and all they are expecting is a read only view, right? Yeah. Even if, even if they don't get the option to cancel restart bills, that's all fine.
But the, the good point in the project, I, I see there's still like old layout that Yes, I know the, the people because they, they have access to settings for the project and they can go to C I C D then under runners. Yeah. They, they, they, they, they, they're, we, we heard some complaints that this is not that super readable.
on project level, I can point out that the on project level, if you go and list the runners, that's where I, I think there are far too many and they're not, you know, properly aligned. Right. That's, that's one area that I can definitely point out. Yeah.
it'll be what is more important is being able to segregate these different type of runners. And that's, you know, and rather than, because if you look at some of our projects where we have, you know, they are further down in the hierarchy, and if you look at runners, then sometimes there are like hundreds of runners available to the, to that project.
And it's not very easy to identify which one, you know, to, to assign and, and even to look at actually what is available. And also from the project level, we don't see the details. I don't know whether that is in your list of items or not on the project level. If you go to the runners, even if you have project runner and if you have the project admin rights, you can't see the runner details right. From that, that view. Yep. And I think the similar thing is on the group runners as well, because the group runner, I can see that some things have changed, but again, on the group runners, the search is not very handy. And when you see the runners on the group level, you, you can't see a lot of details. For example, the simple thing, if if I'm searching on the subgroup level and I see a runner which is available to my group, I can't see on which group level it is re registered to.
Further details
Proposal
Transition the current view to be closer to #361417 (closed) by only including the data available in project runners today in the table. We know that this view is usable from previous solution validation in https://gitlab.com/gitlab-org/ux-research/-/issues/1594 and https://gitlab.com/gitlab-org/ux-research/-/issues/1612. We will not be adding or changing any data shown in this view for this MVC iteration.
Data to be included in the table (same data as shown today):
- Runner ID & short token & locked (if a project runner)
- Status
- Description
- Tags
- Actions (if the user has permissions): Edit, pause/play, delete
Instead of using column sections to distinguish project from group from shared runners, we will make use of tabs. Tabs will include:
- Instance
- Group
- Project
Permissions and Security
Documentation
This would include documentation updates to project runners if we were to do this.
Testing
What does success look like, and how can we measure that?
Users should be able to immediately know which runners are accessible to them to run their project jobs.