GitLab: show pipeline stages as checks, and a failed stage's failed jobs

[TonybynMp4]

What happens today

A GitLab merge request shows its whole head pipeline as one "Pipeline" check. When that check fails, the panel can't tell you which job broke, so you end up opening GitLab anyway. GitHub pull requests list every check. The bug is tracked in #13431.

Proposal

Show the pipeline the way GitLab's own pipeline view does.

• One check per stage (build, test, deploy), with GitLab's status and label for that stage.
• A failed stage is replaced by the jobs that failed it, named like test / unit, each linking to its job log.
• The single "Pipeline" check stays when the stages can't be read or the pipeline has none yet.

Why stages and not every job

My first attempt, #13434, listed every job over REST. It was closed as too large, and fairly so. It paged through jobs, cached finished pipelines and worked out trigger job status by hand. Moving to GraphQL removes all three: one request returns every stage and job with the status GitLab already computed. Listing every job would now be about as small as this change. I went with stages because a pipeline with 40 jobs would mean 40 checks, while stages usually come to 3 to 6 and still point straight at the failure.

How

One GraphQL request reads project.mergeRequest.headPipeline.stages, capped at 100 stages and 100 jobs per stage. It runs in parallel with the existing merge request read, and only for the checks and detail reads. No paging, no cache, no new setting.

I have a PR ready if this direction works for you. It's about 160 lines plus tests, all in packages/source-control-gitlab.

Open questions

1. Is one check per failed job right? The other option keeps a failed stage as one check and names its failed jobs in the description.
2. Should a stage that "passed with warnings" show as success, as it does now, or as neutral?
3. Should manual stages show as neutral, as they do now, or be hidden?
4. Would you rather see every job? With GraphQL that's the same request and only a few lines more.

[oss96]

On question 4, I'd go with every job.

GitHub pull requests list every check run, and Forgejo lists every commit status. A GitLab merge request with stages would be the one host where the panel shows something coarser than what the host shows. With GraphQL the cost difference is gone, as you wrote, since it's the same request.

Stages lose information in two places I ran into while testing #28728 on a self-managed GitLab:

• While a pipeline runs, the check says test is running, not which job. An agent watching the merge request learns job names only once something fails.
• A failed stage shows only its failed jobs, so a job cancelled in that stage vanishes from the list.

The 40-checks worry is real but GitHub already has it. Matrix builds there produce dozens of check runs. The panel sorts failures first and keeps passing checks behind "show all", so a long list mostly sits out of the way.

The mapping from #13431 carries over unchanged: allowed failures become neutral, manual jobs stay neutral, and retried attempts stay out. I have an every-job version of the decoder working locally against the same test pipeline and can share it if that direction is picked.

Written with Claude Opus 5.5 in Claude Code (T3 Code).

[TonybynMp4]

Hmm yeah tbh the original idea of only doing stages was that it would be a smaller PR compared to the original one with caching + deep requests, using GraphQL it would probably add like 15 lines lol