Skip to main content
Connect a source-control provider and Ankra’s AI reviews your pull requests: it reads the diff, posts a verdict with its findings, pins each finding to the line it is about, and answers when somebody mentions it in a comment. Everything is configured in one place: AI → Settings → Connections → Source control & AI review.
Nothing runs until you switch it on. Every capability on a new connection is off. Installing the GitHub App, connecting a GitLab token, or authorising a Bitbucket workspace gives Ankra access, and nothing more: no review is posted, no mention is answered, and no preview is deployed until an organisation admin turns the switch on for that connection or for a single repository.

​
Connect a provider

Each provider appears as its own card. Connecting one is an organisation admin action.
Press Install GitHub App and pick the organisation or user account, then the repositories Ankra may see. You land back on this page with the installation listed.One account can carry several installations, and each is configured separately. See the GitHub integration for the permissions the App requests and how to change which repositories it covers.GitHub is the only provider that also offers PR preview environments.
A connected card shows one row per installation, credential, or workspace. Its one-line summary says which lanes the default row runs and how many repositories deviate from it, so a connection reading Nothing enabled is doing exactly that. Rows that do nothing open collapsed; press the row to expand it.

​
AI mode: Ask or Agent

Every connection carries an AI mode that bounds what the AI may do when it is talked to from that repository. It is separate from the capability switches: the switches decide whether the AI answers, the mode decides how far the answer may go. A connection in Agent mode is marked Can act. Automatic review events themselves stay read-only whatever the mode: a review comments, and a proposed fix arrives as a separate pull request you review like any other. On GitLab and Bitbucket Cloud, Ankra cannot open a pull request, so an Agent-mode reply proposes the fix with a branch name and a commit message instead of offering one.

​
The repository table

Each connection expands into one table of every capability, with two kinds of row.
  • All repositories is the default row. It carries the connection-wide values, and every repository with no rule of its own follows it.
  • A repository rule is one row per repository that should differ. Pick the repository (or type <owner>/<repository>) and press Add rule; the new row starts as a copy of the default row. Removing the rule reverts that repository to the default row.
Every control saves the moment you change it. There is no separate save button on this table. To manage rules from the terminal or a script instead, an organisation admin can use the CLI:
set changes only the switches you pass (--review, --mentions, --previews, --model, --review-drafts, --max-reviews-per-pr; turn one off with =false) and keeps the rest of the repository’s rule, or the default row’s values when the repository has no rule yet. The connection is found from the repository; when that is ambiguous, pass --binding <provider>/<id> as list shows it. list --reachable also lists the repositories each GitHub App installation can see, and unset removes the rule so the repository follows the default row again. Listing needs organisation membership; set and unset need an organisation admin. Over the API, an organisation admin’s API token can send PUT /api/v1/org/ai-gateway/scm-bindings/{provider}/{binding_external_id}/repo-overrides with repo_full_name, ai_review, mention_replies and pr_previews to add or change a rule, and DELETE on the same path with ?repo_full_name=<owner>/<repository> to remove it. GET /api/v1/org/ai-gateway/scm-bindings lists each connection’s binding_external_id and its current rules; the API Reference has the full request shape.
Rules are keyed by the repository path, lowercased. For GitLab, use the full project path including subgroups, up to 20 levels deep - for example my-group/my-subgroup/my-project.

​
What each column means

When nothing picks a review model - not the repository’s Application AI settings, not a repository rule, not the default row - the review runs on your organisation’s AI code review function under Models per function. Unless an admin changes it, that follows the Think tier: GLM 5.3 on the Ankra provider, or your own Think model when the organisation runs on its own key. Every pull request gets that model, whatever the size of its diff.
The cap and the draft switch gate automatic reviews only. Asking for a review in a comment always runs one, though it still counts toward the cap - see Talking to the review below.

​
Review instructions

Customise review instructions, at the top of the section, opens your organisation’s own review prompt, with one field per connected installation. It is what the reviewer should keep in mind on this installation: which areas to weigh heavily, which conventions to enforce, what language to write in.
  • Up to 4,000 characters per installation. The counter turns red past the cap and Save stays disabled until you shorten it.
  • The instructions steer what the review focuses on and how it is phrased. They cannot override the platform guardrails or the review format.
  • Every repository on the installation inherits them. An application that overrode its own Pull request settings under Application AI settings keeps the instructions set there instead, because overriding a lane pins the whole lane.
  • Only organisation admins can change them.

​
What a review posts

One comment per pull request, updated in place on every re-review, never a stream of new ones. Where a pipeline, a preview, or a promotion is also running, they share that comment as separate sections. The review section is laid out like this:
Findings carry a severity of high, medium, or low, and a review keeps to the issues that matter - at most eight. A finding that names a line is also posted as a comment pinned to that line, so it is read where the decision is made. Each inline comment carries an invisible fingerprint of its file and title, so re-reviewing a pull request never restates a finding it has already pinned, even if the line has drifted or the wording changed.

​
How the review reads a change

  • Machine-written files are dropped before the diff is measured. Lockfiles, minified bundles, source maps, and generated protobuf never reach the model. Beyond keeping the cost down, this is what stops a large lockfile from crowding the real change out of the review. Set Ignore paths per repository under Application AI settings to drop more.
  • Uncertain findings are settled, not guessed. When a finding rests on something the diff does not show, Ankra reads the file and either restates the finding as a definite defect or drops it. Where that check cannot run, the finding is posted with its uncertainty visible.
  • A truncated answer says so. If the model runs out of output budget mid-answer, what arrived is posted under an explicit incomplete-review notice rather than as a finished review that found nothing.
  • The diff is treated as text, never as instructions. An instruction planted in a diff or a pull request description asking the reviewer to act, change role, or reveal data is refused.

​
What the review reads beyond the diff

Before it answers, the review also reads the code a change can break outside its diff: other callers of what changed in the same repository, files in related repositories that still use a name the change removes, and the companion pull request that carries the other half of a cross-repository change. A Depends-on: line in the description declares which pull request has to merge first. How each of those works, how to relate two repositories, and what an empty result does and does not mean are covered in Cross-repository review.

​
Talking to the review

Mention @ankraai in a pull request or merge request comment and the AI answers in the thread, with the change as context. This needs Mention replies on for that repository.
  • Ask a question. “@ankraai does this handle the empty case?” gets an answer grounded in the diff, and a plain statement when the diff does not contain the answer.
  • Ask under an inline comment and the question is read as being about that line.
  • Ask for a review. A mention is a direct request from a human, so it is never filtered by draft state, branch scope, or either review budget. It runs even on a draft and even past the Auto reviews / PR cap, and it is counted against both budgets.
On GitHub and GitLab, Ankra reacts to your comment with 👀 as soon as it picks the mention up, so you can tell a slow review from one that never started. Bitbucket Cloud has no comment reactions, so there the reply itself is the first sign; it is posted as a reply to your comment.
Only @ankraai summons the review. It is matched as a whole word, so @ankraai-bot and an address like [email protected] are ignored.

​
When a review does not run

A skipped review is normal and costs nothing. Ankra decides before any model call, in the order below, and stops at the first reason that applies. On GitHub the reason is written to the Ankra AI review check run on that commit: its title reads Review skipped followed by the reason, and its summary says what lifts it. The check run is the one place the decision is recorded. A skipped head is not retried. Nothing on Ankra’s side re-queues a commit it declined; the next push is a new head, judged afresh against the same switches and counts. So once a pull request is over its budget, every later push to it is skipped until the budget changes.

​
The two budgets

Two counters can decline a review, and they are set in different places. The daily budget is checked first, so a repository over both reads daily review budget reached on its check run. Both counters include reviews somebody asked for with @ankraai: a requested review runs past either budget, and it is still counted against both. A completed review of a commit replaces any earlier Review skipped on that commit’s check run, so a review requested with @ankraai clears a check that a budget had concluded.

​
Per-application overrides

The table on this page sets your organisation’s defaults. An application connected to a repository can override them on its own Ankra AI panel, which also exposes branch patterns, ignore paths, daily budgets, input-character budgets, and the deeper lanes. Both surfaces read the same stored settings, so they never disagree. See Application AI settings.

​
Cost

A review is a model completion, billed to your organisation like any other AI usage. Four things keep it bounded, and all four are yours to set:
  1. Every lane is off until you turn it on, per connection or per repository.
  2. Auto reviews / PR caps the reviews one pull request can accumulate.
  3. Review model picks what a review costs. The picker shows each model’s context window and price. With nothing picked, the organisation’s AI code review model applies.
  4. Ignore paths and the input-character budget bound how much of a diff one review reads.
Reviews already spent appear in your AI usage - see Models and Cost.

​
Permissions

Connecting a provider, disconnecting one, changing any switch, and editing the review instructions all require organisation admin. Members see the connections and their current settings, and the controls are disabled with the reason.

​
Troubleshooting