FixControl
GitLab integration

The output is always a merge request

FixControl uses your GitLab connection to read repository and branch context and to open merge requests carrying a proposed patch. Review and merge happen in GitLab, by your team.

MR delivery onlyMerge stays with youCapability health
What it does

What the GitLab connection is used for

Repository & branch context

Repository and branch context comes from your GitLab connection, read inside the bound project and tenant. That context is what a proposed patch is built against.

Proposed merge requests

With a connection that permits it, FixControl opens a merge request carrying the patch. Merging it is not something FixControl does.

Diff & evidence

Reviewers get a standard MR: the diff, plus the evidence that motivated it. Nothing about the change is hidden in a side channel.

Human merge & deploy

Merge and deploy decisions belong to your team, in GitLab and in your pipeline. FixControl’s involvement ends when the MR is open.

Scoped permissions

Everything runs under the permissions of the GitLab connection you create. Grant less, and FixControl can do less — that is the intended shape.

Evidence & audit

Each opened MR has a matching entry in the decision ledger, recorded when the change was approved for delivery.

Capabilities & health

One connection, several separately probed capabilities

Reading a project and opening a merge request are different permissions, and they can be in different states. FixControl checks and displays them independently, so you know before delivery whether the MR path works.

Repository & branch read
Supported

Repository and branch context is read through the connection, inside the bound project and tenant.

Open MR with proposed patch
Configuration-dependent

Needs the connection to hold MR-creation permission on the target project. Dispatched through the integration outbox.

Diff & evidence on the MR
Supported

The proposed change is reviewable as a standard merge request diff, with evidence attached.

Unattended merge or deploy
Not available — by design

Absent by design: FixControl opens MRs and does not merge or deploy. Those remain your team’s calls.

One green status for everything
Not available — by design

Replaced by per-capability status. A connection that reads fine but can’t open MRs shows exactly that.

Failure handling

An MR that didn’t open is a visible failure

Retries, dead-letters, ledger entries
MR creation goes through the integration outbox — retried when transient, dead-lettered when not, and always visible on the operational timeline. The approval behind the change sits in the decision ledger with actor, role, channel, evidence, and consequence; the merge itself is done by someone on your team in GitLab.
FAQ

About the GitLab integration

Does FixControl merge merge requests or deploy on its own?+
It doesn’t. FixControl’s output is an open merge request; your team reviews it in GitLab and decides whether it merges and ships.
What does FixControl need to open an MR?+
A GitLab connection with permission to open merge requests on the target project — the permissions you grant when you create the connection. Without them, reads can keep working while MR-open reports unavailable.
Where do engineers review a proposed change?+
In GitLab, as a standard merge request. The diff and the supporting evidence are on the MR, and the timeline in FixControl shows the same change.
What happens if opening an MR fails?+
The write waits in the outbox and retries. If GitLab keeps rejecting it, the job dead-letters and the failure is flagged on the timeline instead of the MR quietly not existing.
Are GitLab actions audited?+
Yes. The approval that released the change is in the decision ledger, and the MR records the delivery. Auditors can walk from one to the other.

Review an AI-proposed merge request

Book a demo and follow one change from ticket to open MR, with every approval on record.