Merge requests

What this means

Every pipeline that pushes code opens a merge request on GitLab or a pull request on GitHub. The Merge requests page is a single list of every MR or PR Bilbis has opened across all your products.

The shape is the same on both providers - only the name differs. We say "MR" in this app for both, except where a label specifically reads "PR" because it points at GitHub.

When to use it

Find an MR Bilbis opened recently.
Filter by status to see what's still open, what merged, what closed.
Jump from an MR back to the pipeline that produced it.
Confirm that a pipeline did or did not open an MR.

Before you start

A pipeline must have reached Pushing or later. Pipelines that ran as a dry run or stopped early do not appear.
Your team must have opened at least one MR or PR through Bilbis. An organization that has never produced one shows an empty state.
The page reads from your Git provider via Bilbis - no extra setup beyond the Git credential.

Where to find it

Pipelines → MRs in the sidebar.

Status values

Each row carries a status badge. Bilbis mirrors what your Git provider says.

Status	Color	Meaning
Open	Amber	The MR is open and not yet merged or closed. CI may still be running, or it may be waiting for human approval.
Merged	Green	The MR was merged into the target branch. The pipeline behind it is normally Done.
Closed	Muted	The MR was closed without merging - usually a manual close on the provider.

Status is read at refresh time. If someone merges or closes the MR on the provider, the row updates the next time you load the page.

Filters

A row of filter chips sits at the top of the list:

Chip	What it shows
All	Every MR.
Open	Only open MRs.
Merged	Only merged MRs.
Closed	Only closed MRs.

Each chip shows a count next to it.

A search input next to the chips matches:

The MR title.
The repo identifier.
The source branch name.
The numeric MR id.

Search is case-insensitive and matches partial words. Filters and search combine - chip narrows the rows, search narrows them further.

What each row shows

Column	Meaning
Title	The MR title, with the numeric id (`!123` for GitLab, `#123` for GitHub). Click to open on the provider in a new tab.
Status	Badge - Open, Merged, or Closed.
Repo	The repository identifier.
Pipeline	A link back to the Bilbis pipeline that opened the MR.
Created	Relative time when the MR was opened.

The title row also shows the source branch and target branch underneath, in source → target form. The mobile layout collapses these into a card view with the same fields.

Steps

Open an MR on the provider

Click the title in any row. The MR opens in a new tab on GitLab or GitHub.

Jump back to the pipeline

Click the Open link in the Pipeline column. You land on the pipeline detail page for that MR.

Filter to open MRs only

Click the Open chip at the top. The count next to the chip tells you how many are open.

Search for a specific MR

Type into the search box. Matches title, repo, source branch, or MR number.

Clear filters

If filters return zero rows, the empty state offers a Clear filters button. Click it to reset the chip to All and clear the search.

Approving and merging

The MRs page itself does not have approve or merge buttons. Approvals happen in one of three places, depending on how your product is configured:

The merge request page on GitLab or the pull request page on GitHub.
The Approve & Merge button on the pipeline detail page (admin only).
A reply on the linked Jira issue, when configured.

See Clarifications and approvals for the full approval flow.

Auto-merge and the approval window

When a pipeline reaches Awaiting approval with auto-merge enabled, the MR sits open until either:

A person approves through any of the channels above.
The approval window expires and a scheduled job auto-merges.

The MR row stays Open during this period. It flips to Merged once the cron picks up the approval - that takes about 60 seconds.

If your product has auto-merge off and the window expires without an approval, the MR stays Open indefinitely. You'll see it on this page until someone approves or closes it on the provider.

When the cron can't merge

If the provider rejects Bilbis's merge attempt - because CI is failing, the MR is still in draft, the branch is behind, conflicts exist, required approvals are missing, or branch protection rules block it - the corresponding pipeline shows a Merge blocked banner under its approval banner. The MR row here stays Open.

The cron retries the merge every ten minutes. As soon as the named issue is fixed at the source (or the next provider state check passes), the next retry succeeds and the row flips to Merged. See Clarifications and approvals → Merge blocked for the full reason map.

Closed without merging

If you close an MR on the provider without merging, the row flips to Closed on the next page load. The pipeline behind that MR usually ends in Failed because the work didn't reach the target branch. Open the pipeline and check the Diagnostics tab if the reason isn't clear.

Permissions

Action	Who can do it
Read the MRs list	Any role.
Filter and search	Any role.
Click into the provider	Subject to your Git provider's permissions, not Bilbis.
Approve	See Clarifications and approvals.

Problems and fixes

Problem	What to check
The list is empty even though pipelines have run.	Pipelines that didn't reach Pushing - for example, dry runs or runs that failed early - don't open an MR. Check the pipelines list.
An MR is missing from the list.	The provider may have rejected the push. Open the source pipeline and read the Diagnostics and Timeline tabs.
The status hasn't updated since I merged on the provider.	Refresh the page. Bilbis reads status at load time, not over a live connection.
The link to the provider says "Not found".	The MR was deleted on the provider. The row will update on next refresh.
Search returns nothing for a known MR.	Search is partial but case-insensitive. Try the numeric id, the source branch, or a shorter title fragment.
The repo column shows a UUID instead of a slug.	The repo's slug is missing in your product config. Open the repo in Products and set a slug.

Pipeline states - the pipeline's view of the same MR lifecycle.
Review pipeline results - the per-pipeline detail page, including the MR link in the header.
Clarifications and approvals - how approvals reach Bilbis.
Create a pipeline - fields that influence what the resulting MR looks like (branch, target branch, ticket id).

On this page