> For the complete documentation index, see [llms.txt](https://docs.getantidote.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.getantidote.com/welcome-to-antidote/integrations/github-check-runs.md).

# GitHub check runs

See the exploration result on the pull request as a native GitHub check run.

Duku posts a **GitHub check run** on the pull request it explores. GitHub shows the check as *in progress* while the exploration runs, then concludes it with the result and lists the new issues it found, with a link to the exploration in Viewport.

The check is posted by the **Duku AI GitHub App** - the same App that posts PR comments - so, as with comments, no GitHub token is handled in your CI job.

{% hint style="info" %}
The check run and the sticky PR comment are two independent surfaces built from the same exploration. The comment is the full summary; the check run puts the result in the PR's checks list. You can use either or both.
{% endhint %}

### Prerequisites

* The Duku AI GitHub App installed and linked to your Duku organisation. Install the Duku AI GitHub App and link it to your Duku organisation. An org admin opens **Settings → Integrations**, selects **+ Connect** under **Source control & CI/CD**, chooses **GitHub** and selects **Install on GitHub**. If the App is already installed on your GitHub organisation, select **Link existing install** instead. An App installed straight from GitHub is not linked, and Duku posts no PR comments or check runs until it is.
* The App granted the **Checks: Read & write** permission for your organisation. If your organisation installed the App before check runs were available, GitHub prompts an organisation owner to review and approve this added permission. Until it is approved, explorations run normally but no check appears - and once it is approved, Duku creates and concludes the check for explorations from the last seven days, so you do not need to re-run anything.

### Enabling the check

There is no separate flag. Duku creates a check run automatically whenever an exploration is started with **server-managed PR comments** and pull-request context - that is, all three of:

* `serverManagedComment: true`
* `githubRepository` (in `owner/repo` form)
* `githubPrNumber`

If you already use the `preview` GitHub Action, or the any-CI preview flow, or the any-CI environment flow in PR-gate mode, you are already requesting the check. The `environment` GitHub Action does not request a check run.

### The check name

The check appears on the pull request as:

```
Duku Exploration (<your product name>)
```

{% hint style="warning" %}
The check name is keyed to the **product name**, not the repository or PR. If you rename the product in Viewport, the check is renamed too - update any branch protection rule that names it.
{% endhint %}

### How the result maps

| Exploration                                                  | Check conclusion                                            |
| ------------------------------------------------------------ | ----------------------------------------------------------- |
| Finished with no new issues, and at least one run verified   | **success**                                                 |
| Finished with new issues that nobody has resolved or ignored | **neutral** - the new issues are listed in the check output |
| Finished without verifying any run                           | **neutral**                                                 |
| Still running after the timeout (default 120 minutes)        | **neutral**                                                 |

* The check never concludes as a failure. GitHub treats **neutral** as passing, so a required Duku check holds a merge only while the exploration is in progress, never because of what it found.
* After the exploration finishes, the check stays in progress for up to about 30 minutes while Duku settles the issues it found, then concludes.
* If issues arrive after the check concluded, Duku updates the conclusion and output to match.
* The check output summarises the run counts and the issues on the PR (new vs. pre-existing), with a link to the exploration - the same data as the PR comment.

### Failing a pipeline on the result

The check run reports the result; it does not block a merge on issues. To make a CI job pass or fail with the exploration, poll the batch status as shown in Triggering explorations from any CI.