Runner table design is out-dated and doesn’t allow for the addition of more data
Overview
The Admin Area > Runners view needs to be re-designed to allow for more data to be added, as this will act as the building block for future improvements for users with 10,000+ runners. It should be more consistent with other CI/CD views based on this issue.
Guiding Principles
Ultimately this solution should provide administrators with a birds-eye view and configuration management capabilities to administer a fleet (tens of thousands) of GitLab runners easily. We will emphasize actionable insights, simplicity, ease of use, engaging and modern tooling
User stories
As an Admin, I want to view an overview of the data related to my organization's fleet of runners, so I can make effective decisions.
When administering runners for a GitLab instance or group, I need an easy way to determine how many runners are out of date by x versions so that I can help with compliance enforcement. Note - the first step is identifying a runner that is out of date and then locating the runner.
Design proposal
Acceptance criteria
- Place tabs at the top of the page, in the same horizontal area as the Register an instance runner button, where we have 4 tabs:
- All (### - if the number is more than 1000, we will show 1000+)
- Shared (### - if the number is more than 1000, we will show 1000+)
- Group (### - if the number is more than 1000, we will show 1000+)
- Specific (### - if the number is more than 1000, we will show 1000+)
- Only for the All tab, add new
shared
,group
,specific
badges-
Shared
badge: purple-100 bg, purple-800 text -
Group
badge: info variant -
Specific
badge: info variant
-
- Rename the "Status/Type" column to "Status"
- Rename the "Runner" column to "Runner ID"
- Remove the "Projects" and "Jobs" columns
- Include the follow statuses in the "Status" column as badges:
- Online (using the success variant): A runner that contacted this instance within the last 2 hours
- Paused (using the danger variant): A runner that is paused
- Offline (using the neutral variant): A runner that has not contacted this instance within the last 2 hours
- Stale (using the warning variant): A runner that has not connected to GitLab for more than 3 months
- No longer use the Active status, since we can rely on the pause/play button to showcase that
- Use un-clickable labels (gray-100 bg gray-700 text color) to represent tags added by the user in the "Tags" column:
- Only show 4 labels, if there are more, then add
+X more
at the end with the number of additional labels -
+X more
should be 12pxgray-600
- Tooltip of
+X more labels
should appear when hovering over+X more
- Only show 4 labels, if there are more, then add
- Cut long tags off using a ... and show a tooltip on hover with the full tag name
- Include ability to filter by Runner numerical ID as well as Runner token
#343133 (closed) as a follow-on)
Step 2 (to be completed in- Work to provide a consistent experience based on this effort
UX Definition of Done
- Problem has been validated
- Problem is ready to enter workflowready for design
-
User stories and acceptance criteria for MVC have been created
- Reminder: consider edge cases for each user story
- Cross-team dependencies have been identified, if applicable
- Prototypes or mock for each user story have been created
- Solution has been validated (doesn't need additional validation)
-
Pajamas
- UI Component design have been identified
- Pajamas issue is created (new workflow)
- If changes involve copy, Technical Writing and UI text labels have been added
- SSOT of MVC has been updated and labeled workflowready for development
Fields for Table View
Field Name | Available in current UI? | Available in MVC iteration? | On by default | GitLab Plan Availability | Notes |
---|---|---|---|---|---|
Type/State | Yes | Yes - with changes | Yes | Core, Premium, Ultimate | Change "Type/State" to "Type" and display only the runner time value. Consider not including the label "TYPE" in the column heading. Need to determine how best to display the runners state (active or paused) |
Runner | Yes | Yes | Yes | Core, Premium, Ultimate | .... |
Version | Yes | Yes | Yes | Core, Premium, Ultimate | ... |
IP Address | Yes | Yes | Yes | Core, Premium, Ultimate | ... |
Projects | Yes | No | No | Core, Premium, Ultimate | ... |
Jobs | Yes | No | No | Core, Premium, Ultimate | ... |
Tags | Yes | Yes | Yes | Core, Premium, Ultimate | ... |
Last Contact | Yes | Yes | Yes | Core, Premium, Ultimate | .. |
Association | No | No | Yes | Ultimate | The initial proposal is that "association" is a new field. This field aims to provide a visual indicator of the runner association to the instance, group, or project. For example, assume runner name = "infra-gcp-docker" is associated to the roadmap-app-dev group. The calculated value for this field is then as follows: "GRP:roadmap-app-dev". If instead the runner is associated to a project then the calculated value for the PRJ:roadmap-app-dev. If the runner is an instance level or Shared runner then the field value = "instance". |
Owner | No | No | Yes | The initial proposal is that Owner = user that registered the runner. We will need some additional discussion regarding the best approach to automatically derive the value for this field. Another option is to try and implement the concept as shown in the second mockup below. In this the field = "project availability" |