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

🎨 Designs

Figma prototype

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 12px gray-600
    • Tooltip of +X more labels should appear when hovering over +X more
  • 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

Step 2 (to be completed in #343133 (closed) as a follow-on)

  • 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"
Edited by Gina Doyle