Skip to content
GitLab Next
Closed
Created by Gina Doyle@gdoyle🌻Developer

Runner UX Vision: Part 2

Overview

We would like to document the Runner UX Vision for Runner Fleet so that we have something to refer to as we make small iterations to the ideal outcome. In order to do so, we need to break it into smaller areas that we know need to be improved throughout the Runner Enterprise Management epic.

This issue is specifically for the Enterprise Management CI job queues. A summary of the problems we want to solve for in the end product includes:

As of GitLab 14.4, there is very little information available to Priyanka or Sasha as to how soon a CI job may start (especially on GitLab SaaS). If a job doesn’t start running promptly, then users are left wondering why the job won’t run. Questions that Priyanka starts asking that may not be readily available in the UI are as follows:

  • Running Jobs: How many jobs are currently running on the Instance or Group runner that this job is scheduled to run on?

    • Filter runners down by a specific job
    • Lots of extra steps to figure out the shared runner that is running that pipeline (have to go into settings)
    • There is no count of running jobs here
    • What does Recent jobs really mean?

  • Pending Jobs: How many jobs are in the queue for this Instance or Group runner that this job is scheduled to run on?

    • No information showing that today in runner details
    • Can you filter on the jobs table by a runner?
      • You can see pending jobs
      • You can see the column for runners but only see the numerical ID
    • Need to improve the way we can show the data here
    • Need to be able to see if a runner is busy

  • What is the age of the oldest job in the queue for this Instance or Group runner that this job is scheduled to run on?

    • Answering the question of when a specific job will be taken on
    • Calculate how long it will take for the job to get serviced
    • If the job queue is super overloaded, we want to give an indication of wait times

  • Is the runner busy?

    • Monitoring the number of jobs are in queue = busy
    • Maybe do not tackle autoscaling runners for this solution
    • Executor type would be autoscaling
      • Shell - non-autoscaling and installed locally
      • Depends on what is running on the machine
    • Docker - non-autoscaling
      • Docker machine - autoscaling
    • Is the runner currently serving a job? - is that busy?
    • Is the runner servicing a job right and can’t handle servicing another job?

Some notes to consider around managing runners on GitLab Saas:

  • Uses Grafana
  • Only uses autoscaled runners
    • We only offer a few shared runners
    • Autoscaling runners will show up as one runner, but it handles hundreds of thousands of jobs - not the case for non-autoscaling runners
    • Autoscaling runners are busy by a different definition

Supporting research

Mural - GitLab team members only

Wireframes (product)

Runner Fleet Evolution Brainstorm Mural

✅ Designs

🎨 See designs in design management

Prototype in Figma

✅ Video walkthrough

🎥 Unfiltered video

WIP Runner UX page and updated direction page

We should also consider creating a first pass at a new Runner UX page, which would be a place in the handbook to include this SSOT.

Edited by Gina Doyle