Pull requests in the console

Every pull request MergeHarbor reviews has a page in the console (Pull requests, then pick one). The Overview tab has the review summary, the findings and the review history. The Files tab has the changes.

Files

The Files tab shows every changed file with the file tree beside it.

• Unified or split. Switch between one column and side by side. The choice is remembered in your browser.
• Findings at their lines. Each MergeHarbor finding appears under the line it is about. Select it to read the explanation and the suggested change.
• Viewed. Tick Viewed on a file to collapse it. The mark is yours alone, and it clears itself when a new push changes that file.
• Hide whitespace. Lines that differ only in spaces or indentation are shown as unchanged.
• More context. Select Show more lines above or below a change to see the unchanged code around it.
• Large pull requests. Very large files load when you scroll to them. Files over 1 MiB are not shown; open them on the code host.

The diff comes from your code host (GitHub through the MergeHarbor GitHub App, GitLab, Bitbucket, Gitea or Azure DevOps) and is cached for the commit you are looking at. Use the refresh button to fetch it again after a push.

Findings posted early

Serious, high-confidence findings do not wait for the whole review. MergeHarbor posts them on the pull request as soon as it has them, with a short note that the full review is on its way:

• From the automatic checks. Problems the deterministic checks catch (for example a committed secret) are posted seconds after MergeHarbor reads the change, while the model is still reviewing.
• From the first finished part of a large pull request. Large pull requests are reviewed in parts at the same time; the first part to finish shares its findings straight away.

When the full review arrives it adds everything else and the summary, and it does not repeat what was already posted. In the console:

• While a review is running, the Review summary says how many findings are already on the pull request.
• Findings shared this way carry a Posted early label.
• Review history shows how long the first comment took for each run.

Only critical and major findings the review is highly confident about are posted early. Turn it off for your organization in Settings → Review behaviour (Post serious findings early), for one repository on its settings page, or with early_findings: false in .mergeharbor.yml. Self-hosted operators can change this with REVIEW_PROGRESSIVE, REVIEW_EARLY_MIN_CONFIDENCE, REVIEW_EARLY_MIN_SEVERITY and REVIEW_EARLY_MAX_POSTS on the server.

Walkthrough

For pull requests bigger than a couple of small files, the review also produces a Walkthrough: a few ordered steps that take you through the change in a sensible reading order, usually the core change first, then the code that uses it, then tests and configuration. Each step explains what changed and why it matters, with just that step’s code below it.

• Move between steps with Previous and Next, or the ← and → keys.
• On the Overview tab, a file with findings links to the walkthrough step that covers it.
• The reviewer writes the walkthrough in the same pass as the summary, so it adds no review time. When it could not (for example, when every file was unchanged since an earlier review), MergeHarbor outlines the change from the diff instead and says so.

Ask MergeHarbor

Open Ask on a pull request (or press Q) to ask questions about the change: what it does, what it could break, why a finding matters, or to draw a diagram of a flow. Answers stream in as they are written and list the code they rely on; select a reference to open the diff at that line.

• Attach code. In Files, select a line number (shift-click another to extend the range), then Ask about these lines. Files and findings have Ask about this too.
• Conversations are shared. Everyone who can see the pull request can read them. Starting one needs permission to review.
• Stop at any time with Stop; what was written so far is kept.
• Cost. Answers are metered: every 10 answers on a pull request use one credit, and your organization’s budget applies.
• Linked issues. If an administrator shares Jira or Linear with conversations, answers can use the issues the pull request names.

Questions on the pull request

You can also ask MergeHarbor on the code host, and it answers in the same thread:

• Mention it with a question: @mergeharbor why is this lock needed?
• Reply with a question to one of its review comments, for example “How would you fix this?”. No mention is needed.
• Ask for a diagram: @mergeharbor generate a sequence diagram (or class, ER or flow diagram).

Each comment is answered once. These questions and answers also appear in the console under Ask, in the conversation called “Questions on the code host”, and are metered like questions asked in the console.

Who can ask. Anyone can comment on a pull request, so MergeHarbor answers only people your organization trusts with the code:

• accounts that can push to the repository (write access or better, as the code host reports it: GitHub, GitLab, Gitea and Forgejo), and
• members of your MergeHarbor organization whose code-host login is linked (the same logins that count for console access).

On other code hosts, and when the host cannot be asked, only linked members are answered. Other comments, on private and public repositories alike, are left unanswered; the webhook log and the audit log record why. Each person can ask up to 20 questions an hour in an organization. Answers to people who are not members, and every answer on a public repository, use this repository only, never its related repositories.

Actions and shortcuts

Besides Merge and Close, the ⋯ menu on a pull request offers the actions your code host supports: approve, request changes, convert to draft or mark ready, reopen, and update the branch with its base. In Files, select a line number and choose Comment, or press T on the line under the pointer. Actions are taken by MergeHarbor’s connection to your code host and recorded in the audit log.

In the pull request list, select several pull requests to re-review, approve, merge or close them together; MergeHarbor shows what will happen first, then the result for each.

Press ? anywhere for the keyboard shortcuts available on that page. R marks a pull request as reviewed by you; the mark is yours alone and shows when new commits arrive after it.

The pull request list

• Impact. The list starts with pull requests whose impact is high or critical. Select the impact filter again to see every pull request.
• Open or closed. Switch with the state buttons or Shift O.
• Reviewed by you. Pull requests you marked reviewed show a check; it turns amber when new commits arrive. Filter with Reviewed by me.
• Saved views. Under Views, save the current filters under a name and apply them later. Views are personal.
• Tier and credits. The tier of the latest review and the credits the pull request has used.