> ## Documentation Index
> Fetch the complete documentation index at: https://docs.borghq.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Automatic Retests

> Link a fix to a finding and let Odin verify it the moment your pull request merges

Fixing a finding is only half the loop — someone still has to confirm the fix actually worked. Automatic retests close that loop for you: link the pull request that fixes a finding, and when it merges, Odin reviews the merged code change and decides whether the finding is resolved. There's no separate retest to request by hand.

This sits at the end of the finding lifecycle, between **Mitigating** and **Fixed & Retested**. See [Finding status](/platform/findings#finding-status) for the full lifecycle.

<Info>
  Automatic verification reviews the **merged code change**. A finding with no linked pull request can't be retested automatically — the merged diff is what the retest reads.
</Info>

## Prerequisites

Three things need to be in place for a retest to fire automatically:

<Steps>
  <Step title="Connect GitHub">
    Install the Borg GitHub App so Odin can read your repositories and receive pull request events. See the [GitHub integration](/platform/integrations/github).
  </Step>

  <Step title="Turn on Automatic retests">
    On the GitHub card in **Management > Integrations**, enable **Automatic retests**. When off, merging a fix updates the linked PR's state but doesn't trigger a retest.
  </Step>

  <Step title="Link the pull request that fixes the finding">
    The fix has to be connected to the finding. There are three ways to do this, covered next.
  </Step>
</Steps>

## Linking a pull request to a finding

Every finding has a unique, human-readable identifier made from your [organisation's finding prefix](/platform/organisation-settings) and a sequence number — for example `BORG-12`. It's shown in the finding header and on every list row, and it's how Odin connects a finding to your engineering work.

When the [GitHub integration](/platform/integrations/github) is connected, Odin watches incoming pull requests for a `{PREFIX}-{N}` identifier in three places, in priority order:

1. **The branch name** (highest priority)
2. **The pull request title**
3. **The pull request body**

If a token matches a finding in your organisation, that PR is linked automatically. The link shows as a chip in the finding header, and the source — branch, title, or description — is recorded so you can tell where it came from. There are three practical ways to make a link happen.

### 1. Copy the generated branch name (fastest)

The finding detail header has a **Copy branch name** action. It gives you a ready-to-use git branch name that combines the identifier and a slugified title:

```text theme={null}
fix/borg-12-sql-injection-in-login-form
```

Paste it into `git checkout -b`, push your fix, and open the PR — because the identifier is in the branch name (the highest-priority source), the PR links automatically the moment it's opened. This is the recommended path: nothing to remember, nothing to type.

### 2. Reference the identifier in the PR title or body

If you branched some other way, just mention the identifier when you open the pull request. Any of these link the PR automatically:

* A title like `BORG-12: fix SQL injection in login form`
* A body that mentions the finding, such as `Fixes BORG-12`

The same detection runs each time the PR is opened or edited, so adding the identifier to an existing PR links it too.

### 3. Link a pull request manually

Sometimes a PR fixes a finding without mentioning it anywhere Odin looks. Choose **Link a pull request** from the finding's action menu to connect it by hand (needs the GitHub integration and permission to update the finding).

The dialog lists recent pull requests, scoped to the finding's repository when Odin knows it, searchable by number, title, author, or branch. Pick one to link it, or paste a GitHub PR URL if it isn't in the list.

<Tip>
  Only manually linked pull requests can be removed. Unlink one from the dialog if you picked the wrong PR — auto-linked PRs are managed by Odin and would be re-created on the next PR event.
</Tip>

### What linking does to the finding

* **Linked PRs show as chips** in the finding header, each labelled with how it was linked (branch name, title, description, or manually). The chip tracks the PR's state as it moves through GitHub — open, merged, or closed.
* **A PR linked to a Reported finding auto-transitions it to Mitigating**, a clear signal to Borg's analyst team that work is in progress. A finding already further along keeps its status.
* **Merging a PR does not, on its own, move the finding to Fixed & Retested.** In `develop → staging → production` workflows, merging to `develop` doesn't mean the fix is live. What the merge does trigger is the retest below.

## What happens when your PR merges

When a pull request linked to a finding merges, and the finding is still open (Reported, Acknowledged, Mitigating, or Open for Retest), Odin queues an automatic retest — provided **Automatic retests** is on for the GitHub integration.

Odin then:

1. Checks out your repository at the **merge commit**
2. Extracts the code change the PR introduced (the diff between its base and head)
3. Reviews that change against the original finding — is the root cause actually addressed, is the fix complete, can it be bypassed, and does it introduce any regressions?

The review looks past the symptom to the underlying cause (for example, SQL injection means checking for parameterised queries, not just that one string was escaped), and reads the surrounding files to confirm the fix holds across every code path.

<Info>
  The retest reads a **snapshot of your code at the merge commit** to run the review, then discards it. It never writes to your repository — no commits, no comments, no pull requests.
</Info>

## Retest outcomes

A retest resolves to one of three outcomes:

| Outcome               | What it means                                                           | Finding status                                                            |
| --------------------- | ----------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| **Fix verified**      | The change addresses the root cause with confidence                     | Moves to **Fixed & Retested**                                             |
| **Fix is incomplete** | The change doesn't fully resolve the finding, or introduces a new issue | Moves to **Needs Revision**, with a comment explaining what's still wrong |
| **Inconclusive**      | The review couldn't confirm the fix either way                          | No status change — the finding stays where it was                         |

<Note>
  **Fixed & Retested** is the one status only Borg can confirm. An inconclusive retest leaves the finding open so you can adjust the fix and merge again, or move it to **Open for Retest** for Borg's analyst team to verify by hand.
</Note>

## Following a retest

You don't have to watch for the result — it surfaces across the Findings UI as it happens.

* **In the findings list**, a chip appears next to the finding's title: **Retesting** while the review runs, then **Verified** or **Retest failed** once it completes.
* **On the finding detail**, a banner reports the same states — a fix being retested, a verified fix, or an incomplete fix that needs revision. When a finding is waiting on a fix, the banner instead prompts you to link a pull request and merge it.
* **Click View retest** for the full picture:
  * The outcome and the reasoning behind it
  * A **How this retest ran** timeline — the pull request that triggered it, followed by the code review step and its verdict
  * A **Spotted while retesting** section listing any related issues Odin noticed while reviewing the change, each with the file, line, and a short description

<Note>
  Issues in **Spotted while retesting** are observations attached to the retest, to give you a heads-up — they aren't raised as new findings automatically. Flag anything worth tracking to Borg's analyst team in the finding [discussion](/platform/findings#discussion-and-activity).
</Note>

## When a retest doesn't run

A retest is skipped, rather than run, when:

* **The finding has no linked pull request** — there's no merged code change to review. Link a PR first.
* **The PR was merged before it was linked** — linking a PR that's already merged doesn't retest retroactively. Move the finding to **Open for Retest** yourself when you're ready for Borg to verify it.
* **Automatic retests is off** for the GitHub integration, or the finding is already **Fixed & Retested**.
* **The finding is in Needs Revision.** Resume mitigation first, then merge your next fix, so the retest fires on the new change.
* **Your organisation is out of credits** and auto-deposit is off. The retest is skipped and shown as such on the finding; top up or enable auto-deposit under [Billing](/platform/billing), then merge again or move the finding to **Open for Retest**.

<CardGroup cols={2}>
  <Card title="GitHub integration" icon="github" href="/platform/integrations/github">
    Connect GitHub and turn on Automatic retests
  </Card>

  <Card title="Findings" icon="magnifying-glass" href="/platform/findings">
    Track findings through the full remediation lifecycle
  </Card>
</CardGroup>