When the gate blocks a merge

The merge gate is Earnie’s decision on whether a pull request (GitHub) or merge request (GitLab) can merge. When someone opens or updates one, Earnie scans the change, checks its findings against the project’s policies, and reports the result on it. This page says “pull request” throughout. Everything on it also applies to a GitLab merge request unless a note says otherwise. This page explains what Earnie posts on a pull request, how to control which pull requests it checks, and what to do when a policy blocks a merge. Before you start:

• Connect the project’s repository through the Earnie GitHub App or a GitLab token. See Connecting a repository.
• Attach at least one policy to the project. Without a policy, the gate has nothing to check.

​

What Earnie posts on a pull request

Each completed pull-request scan produces three things, on GitHub and GitLab: Earnie publishes one review for each completed pull-request scan. On GitHub it’s a COMMENT review, and on GitLab it’s the equivalent.

​

Inline comments on the changed lines

Earnie places an inline comment only when a finding meets all of these conditions:

• No approval covers it.
• It’s new, and Earnie can attribute it to this pull request.
• It overlaps a line the pull request added.

If the provider’s record of the changed lines is missing or incomplete, Earnie doesn’t guess where a finding belongs. It puts that finding in the summary comment instead. Findings beyond the project’s comment cap also go in the summary comment. Every inline comment has the same sections in the same order: What, Why, Evidence, Remediation, Links, and a Prompt you can copy into a coding agent. The remediation uses the best evidence Earnie already has, for example an explicit fixed version or a policy parameter. When Earnie doesn’t know an exact fix, it suggests the next step it can support with evidence. By default, inline comments start at Medium severity, with at most ten per review. A project can change both. See Choosing which pull requests Earnie checks.

​

When a finding is resolved

• If a later push removes the finding, Earnie replies with the commit that resolved it and resolves its review thread.
• If a person resolves the thread while the finding still exists, Earnie treats that as an acknowledgement for this pull request and doesn’t reopen the thread. If a finding returns after Earnie resolved its thread automatically, it can get a new thread.

An acknowledgement is not a Policy Approval. It doesn’t change the finding or the project’s gate.

​

The summary comment

By default, Earnie posts the summary comment whether the gate passes or fails, so a clean pull request also has a record of what Earnie checked. You can set a project to comment only when the gate fails. Even then, if a pull request already has a summary comment, Earnie updates it when the pull request passes. A failing verdict doesn’t stay on the pull request after the fix.

​

When the branch you’re merging into moves

Earnie measures a pull request’s result against the commit the pull request was branched from. If someone merges or pushes to that base branch, the result may no longer describe what merging would produce. Earnie marks the old result as out of date:

1. Earnie scans the new head of the default branch.
2. When that scan finishes, the Earnie check on every open pull request still based on the old head turns neutral, with the text Base branch moved; result is not conclusive.
3. Push a commit or re-run the scan, and the check gives a real result again.

Neutral is not a failure. Earnie hasn’t found anything wrong, and it hasn’t cleared anything either. Earnie doesn’t re-scan any pull request for this. The check only reports that its result is out of date. Earnie leaves merged and closed pull requests as they are, because their checks record a decision that was already taken, and Earnie doesn’t rewrite those.

​

Choosing which pull requests Earnie checks

On a busy repository, not every pull request needs a check. An Operator or Admin can choose which pull requests Earnie scans, and how much it writes, in the Pull-request feedback card at Project → Scan Configuration. The card has seven controls: None of these controls changes a verdict. They decide which pull requests Earnie scans and how much it writes. Earnie judges every pull request it scans against the same policies, and no setting here can turn a block into a pass. The path and base-branch controls fail toward scanning. If Earnie can’t find out which files a pull request touched, or can see only part of the list, it scans the pull request instead of skipping it.

​

Setting the controls for the whole organisation

The same controls are available for every project at Settings → Scan Configuration. Turn on Lock these controls for every project to make every project use the organisation’s values. While the lock is on:

• Each project’s form is read-only and says that your organisation has locked these controls.
• Earnie keeps each project’s own saved choices. They take effect again when an Admin turns the lock off.

​

Three routes when a policy blocks a merge

When a policy blocks a pull request, someone has to make a decision, and Earnie records it. The pull request shows the finding, the rule that fired, and the evidence. You have three routes, and each one leaves a record of who decided and why:

​

Route 1: Fix it

Upgrade or replace the component. The next scan re-evaluates the change, and the gate clears without further action.

​

Route 2: Correct the finding

A finding can be wrong. For example, your own code matched a published copy of it, or Earnie identified the wrong package. In that case, triage it. Marking a finding as original removes it from the gate, because the policy doesn’t apply to it.

​

Route 3: Request an approval

When the risk is real, understood, and accepted, request a Policy Approval. It’s a recorded decision that a specific finding may pass despite the policy.

1. Open the finding in Review, or open the policy and find the finding in its violations table.
2. Select Request approval.
3. Fill in the three fields:
   • Justification category says why the finding doesn’t apply or is acceptable. The options are Component not present, Vulnerable code not present, Vulnerable code not in execute path, Vulnerable code cannot be controlled by adversary, Inline mitigations exist, Fixed, Under investigation, Incorrect data, and Other.
   • Justification is your reasoning, in your own words.
   • Expiry is 30 days (the default), 90 days, Custom date, or No expiry (not recommended).
4. Select Request approval to submit.

​

What happens next

1. The request is pending. The finding shows Pending approval. A pending request doesn’t change the verdict.
2. An Admin reviews it. Only someone with approval authority, which means an Admin, can decide. They select Approve or Reject and record their own reason.
3. Only an approval clears the finding. The gate holds it until then.

Rejected and pending requests both stay in the finding’s history. Earnie discards nothing, so the record shows every request, not only the one that was approved.

​

How an approval updates the pull request

When an approval clears a gate, Earnie updates the Earnie check and the comment for the same scan right away. The decision shows up on the pull request without anyone pushing a commit. Earnie doesn’t re-scan or re-evaluate anything. The scan, its findings, and the policy revisions it was judged against stay the same. Only the approval is new, and the check now reflects it. The check turns green only if the approval cleared every violation still holding the gate. If another violation has no approval, the check stays red. Revoking an approval updates the pull request the same way, in reverse.

​

Finding what’s waiting on you

An Admin can find pending requests without opening each policy. The project’s Policies page has an Approvals tab next to All policies. It counts the requests still awaiting a decision across every policy attached to the project. It counts pending requests only, so it shows zero once the queue is clear.

• Approve or Reject a request from its row.
• Use the Status filter to list Approved, Rejected, or Revoked requests instead.
• To withdraw an approval you’ve already granted, find it under Approved and select Revoke. You can revoke only approvals that haven’t expired.

​

What’s next

The merge gate checks a change once it reaches a pull request. The Earnie CLI applies the same policies earlier, in CI pipelines, in a pre-commit hook on a developer’s machine, and in coding agents.