[Bug]: GitLab merge requests show the whole pipeline as one check

[antony-bouyon]

Area

apps/server

Steps to reproduce

1. Connect a GitLab project whose merge request pipelines have more than one job.
2. Open a merge request while its pipeline is running, then again after a job fails.
3. Look at the checks summary on the merge request's Summary tab.

Expected behavior

One check per CI job, like GitHub pull requests get, so a failed or running check names the job and links to it.

Actual behavior

The whole pipeline shows up as a single check called "Pipeline". While it runs, the header reads "1 of 1 running". When it fails, you can't tell which job failed without opening GitLab.

It can also show a pass that isn't one. A trigger job without strategy: depend succeeds as soon as it starts its child pipeline. If that child pipeline then fails, the parent pipeline stays green, and so does the single check.

The cause is toChecks in apps/server/src/pullRequest/gitLabMergeRequestJson.ts. It maps the merge request's head_pipeline to one check and never reads the jobs. The comment above it says GitLab has no per-job list for a merge request. The merge request endpoint doesn't have one, but GET /projects/:id/pipelines/:pipeline_id/jobs and .../bridges do, and the second one reports each child pipeline's own status.

Impact

Minor bug or occasional failure

Version or commit

main @ e67abcf

Environment

Linux, desktop app, GitLab via glab

Workaround

Click through to the pipeline on GitLab.

Fix

I have a fix working locally and can open a PR. The merge request detail reads the head pipeline's jobs and trigger jobs, and shows one check per job. A trigger job takes the status and link of the pipeline it started. If either read fails or returns a full page, it falls back to today's single "Pipeline" check.

[juliusmarminge]

Confirmed on current main. This is still what a merge request detail reports, and it has not changed since the GitLab checks mapping landed.

getMergeRequestDetail only reads the merge request (include_diverged_commits_count=true). toChecks in apps/server/src/pullRequest/gitLabMergeRequestJson.ts then turns head_pipeline into one check named "Pipeline". The Summary tab and the detail header both render detail.checks, and one pending check is exactly the "1 of 1 running" line. The decoder keeps status, web_url, and source from that object and drops id and project_id, so the detail read has no pipeline id to ask for jobs even though GitLab sends one.

The comment above toChecks is only half right. The merge request payload has no job list. GET /projects/:id/pipelines/:pipeline_id/jobs does, and it does not include trigger jobs (Ci::JobsFinder without type: Ci::Bridge). Those are a second list. Current docs call that GET .../trigger_jobs. GET .../bridges is deprecated as of GitLab 19.2 and still served by the same presenter, so it is the compatible name for older self-managed instances. Default page size on both is 20, and per_page stops at 100.

Two consequences for the fix you described:

• Per-job checks alone do not fix the false pass. Without strategy: depend, GitLab marks the trigger job successful as soon as it creates the child, and head_pipeline.status stays success if that child later fails. The single "Pipeline" check is an accurate copy of that parent status. The child failure shows up only if the trigger row uses downstream_pipeline.status and downstream_pipeline.web_url when that object is present. That will make this header red while GitLab's own pipeline badge is still green. That is the right reading of this issue, and it should stay explicit in the PR. If downstream_pipeline is null, keep the trigger job's own status. This does not expand jobs inside the child, only the one downstream pipeline.
• A failed job with allow_failure: true must not become a failure check. The header treats any failure or cancelled as "N of M failing", so an allowed failure would mark a pipeline GitLab considers green. neutral matches how manual and scheduled are already treated. Retried attempts should stay out (include_retried defaults to false).

Please keep the extra reads best-effort inside mergeRequestDetail, not in the pure decoder. A jobs or trigger read that errors, or a page that comes back full, should leave the merge request detail up and fall back to today's one "Pipeline" check. A full page is ambiguous with a pipeline of exactly 100 jobs, and a partial page sorted newest-first can omit the job that failed. An empty successful read should use that same fallback rather than "No checks reported". Fetch with head_pipeline.project_id and head_pipeline.id. On a fork those often differ from the target project, and the target path 404s.

The list row is a separate gap: GitLab list items never set checksState, so this change is the detail header and the Checks section only.

No existing issue covers this. A PR with the fallback above is welcome.