Merge requests

What you’ll learn

• Where to find and inspect each merge request.
• How to get review notes fixed by Claude.
• How merging, closing and deleting work, and who may do them.
• Why a button can be greyed out.

One merge request per repository

During Build, Claude opens one merge request per repository. You follow them on the Build page under Merge requests, and each has its own page in Livra.

On the Build page, find the merge request and click Changes and actions (or Changes). You see:

• Changes — file by file, with line numbers. Large or binary files link to GitLab.
• Can it merge? — conflicts, how far it is behind its target branch, and GitLab's status.
• Pipeline and its jobs.
• Approvals and open Review threads.

Open in GitLab takes you to the same merge request in GitLab.

Review notes

Comments your team leaves in GitLab show on the Build page as review notes, with how many are still open. Click Ask Claude to address open notes to send Claude to fix them. It pushes the changes after your approval, like any other push.

Example: a reviewer comments on the team-invites API merge request: "Check the invitation’s expiry date on the server." You click Ask Claude to address open notes, approve the push, and the reviewer sees the fix in the same merge request.

Claude's review, and a failed pipeline

On a merge request's page, Ask Claude to review gives a careful read of the changes — bugs, security, missing tests. It stays in Livra until you choose Post as a comment on GitLab…; then it appears as your comment, marked as Claude's review.

When The pipeline failed, the page shows the failed jobs and the end of their logs. Ask Claude to fix the pipeline sends Claude to fix it on the same branch; the push waits for your approval, like any other.

Merge, close or delete

Under Actions:

1. Merge… — choose how (merge commit, squash and merge, or rebase then merge — whichever your organisation allows) and whether to delete the source branch, then Merge now.
2. Close… — closes it without merging. Its branch and commits stay; it can be reopened in GitLab.
3. Delete… — removes it from GitLab for good (GitLab allows this only to project owners). Type its number to confirm. The branch stays.

These are always done as you, with your own GitLab account — never by Claude, and never with the organisation's account.

Tip: connect your own GitLab before your first merge. Without it, the merge button tells you to.

When a button is greyed out

The reason is shown on it and under it, for example:

• your organisation requires a passing pipeline, and it failed;
• it has conflicts with its target branch;
• in your organisation, only the Org Owner and admins can merge;
• you need to connect your own GitLab account.

Fix the cause, or ask someone allowed to act, then come back: the page reads GitLab again, and the server checks everything once more before acting. Your organisation sets these rules in its merge request settings.

Tip: only the feature's own merge requests can be acted on here, and every action — and every refusal — is recorded in the audit log.

Check yourself

1. Who performs a merge done from the merge request's page?

You, with your own GitLab account. Never Claude, never the organisation's account.

2. A reviewer left three comments in GitLab. How do you get them fixed?

Click Ask Claude to address open notes on the Build page, then approve the push.

3. Does deleting a merge request delete its branch?

No. The merge request is removed from GitLab; the branch stays.