Skip to content

Beautifying of our UI 17.1 - Merge trains + Runners

Who'll take part and when?

Milestone 17.1

Product Design Front-end Engineering
@veethika @mrincon

Business need

Through this work, we'll focus on Driving use-case adoption for CI. This is a FY25 R&D Investment Themes for GitLab.

...ensuring that customers realize the value of the capabilities they have paid for.

Theme

Improve workflows for merge trains and runners so users can see value in the features sooner.

Prioritization

FigJam canvas

Final issues

Issue Design ready? Design review volunteer Merge request

Follow-up from "Fixed outdated text" (Improve runner empty stat...

Irrelevant

Remove "Retry all failed jobs" button from Merge Train

Fixes "retryable" value for merge train pipelin... (!152785 - merged)

Present an option to retry jobs in a merge train pipeline while its still running

Allow retry of merge train pipeline while its r... (!154916 - merged)

Allow individual jobs to be retried in running ... (!155042 - closed)

Warning added for merge train pipeline appears for merged res...

Set Auto-merge cannot be chosen while Merge Trains enabled

May include heavy-lifting, not fit for BofUI

UX improvements for merge train removal (#429263)

Fix split in 3: !153954 (merged), !153973 (merged) and !153974 (merged)

Improve Merge Train messaging for when a Merge Request fails...

Stretch: Support MR search scope for pipelines

Stretch:

MRs removed from the merge trains due to configuration, but no details are left about what that configuration is

In discussion to finalize proposal

Stretch: Update job stuck error message due to CI job tags not matching tags assigned to runners

What would this pairing/partnership look like?

  • Self-Directed: There are no restrictions on where in the product the pair can make improvements. The goal is to empower the pair to focus on usability improvements that they personally want to see fixed in a product that they use themselves almost every day.
  • Area focused pairing and prioritization: The Product Designer and Engineer pair do not need to be from the same stage group. This is a voluntary initiative.
    • The Product Designer and Engineer(s) will inform their stage group team of their involvement in the initiative, so that they can make time for it during milestone planning.
  • Work in MRs, not issues: Both the Product Designer and the Engineer should work directly in MRs to make changes. For the Product Designer, these MRs will likely be focused on less complex usability issues that the pair identifies, such as documentation, minor UI polish, or UI text changes.
Edited by Miguel Rincon