Skip to content

Admin Area Recent Builds Served By This Runner additional columns for branch, and task, and execution time?

Description

Currently in the Admin Area, under Runners, each runner has a grid showing recent builds served by this runner, with the following information per recent build task executed:

Recent builds served by this runner

  • Build
  • Status
  • Project
  • Commit
  • Finished at

Each line represents exactly ONE task, which might be named "build", or "test" or "deploy_to_staging". Information critical to my understanding of the use and the health of the runner is currently NOT visible to me at this level.

Proposal

The following should be ADDED to the existing columns:

  • which branch was build executed against? Master? feature/1234?
  • which job (build_html,test_webdriver,deploy_staging) ran? The job name is more important than the ID in this case.
  • what deployment Environment was used? - what was the total execution time?

screenshot: recent

Reasons why these matter:

  • There is a lot of uncertainty at the top level. I find myself clicking in and viewing each build, and having to do that for every row to get the picture of what built.
  • Most often I check which task (typically one of the build, or test, or deploy of some kind) ran. The actual name of the task in .gitlab-ci.yml is valuable to me.
  • The information is MOST important to me when I have to see patterns in FAILING builds. A field of green is not something that I take an active investigation into.
  • The second most important kind of thing to me is that Gitlab-CI runners are not keeping up with load. I want to know which tasks are taking a long time. Sometimes the unit-test task that took 30 seconds yesterday is taking 30 minutes. Only seeing when something FINISHED is not good enough for me.
  • Once I start using Environments, knowing which environment a build used could be incredibly important.

Reasons why these matter at the per-runner level:

  • We have to find out if we're running enough runner VMs and we have to see when that runner is over-utilized, or when tasks inside it start taking too long (perhaps because the VM host is over-provisioned, and has no I/O bandwidth).

  • Sometimes environment issues (failed builds due to some tooling-updates issue on the runner) are made harder to diagnose because patterns that could have been made visible at the top are not visible

Links / references

  • none yet.
Edited by Gina Doyle