Job failures should be distinguishable between "infrastructure" and "build" problems

Release notes

Problem to solve

As a Sidney or an Isaac, or an Ingrid, I want visibility into jobs failing due to items under my control. That is, I want to be able to distinguish between jobs failing as the result of a build failure (i.e. something under the project teams' developers' control), versus an infra failure (i.e. something under the service operators' control).

This problem exists with both shared fleets of runners, or with "bring your own runners".

Infrastructure failure scenarios

1. Failure to pull container image required in CI job from the source image registry. example
2. ContainersNotReady failures during pod instantiation by a kubernetes runner-manager
3. "ERROR: Machine creation failed" failures during machine instantiation by a docker+machine runner-manager

Proposal

Have gitlab-runner report back to rails differently depending on the exit code, or the point of failure within job execution, such that the rails application can present job failures differently if they're suspected to be the fault of "infrastructure" (or things ancillary to the execution of the job itself).

The GitLab application should show these failures differently, so that it's easier for developers to visually spot where problems they are empowered to address exist, versus problems they should be reporting back to the operator(s) of the instance.

This benefits personas that operate GitLab, benefits developers, and should also speed time in identifying problems and potentially shorten MTTR during incidents.

Intended users

• Sidney (Systems Administrator)
• Ingrid (Infrastructure Operator)
• Isaac (Infrastructure Engineer)

Feature Usage Metrics

This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.