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

# Pull request checks

> What Mini posts on your GitHub pull requests, how your team starts a run from one, and how to make the check block a merge.

On GitHub, Mini comments on the pull requests that touch your app, runs the scenarios when someone asks, and posts a check with the verdict. This page covers that comment, the check, the merge gate and how to choose which scenarios run. It needs the [Minitap GitHub App](https://www.minitap.ai/docs/minitest/integrations/github.md) installed and the app linked to its repository.

## The pull request comment

Mini posts one comment per pull request and keeps editing it as things change.

**1. Mini introduces itself**

It names the app the pull request touches, works out which scenarios the change affects, and offers a box to tick: **Run affected**. When a pull request touches several apps, each app gets its own section, plus **Run affected across all apps**. Nothing runs until someone asks.

**2. Someone starts the run**

Tick the box, or comment `@mini test <app-slug>` on the pull request. Mini runs the scenarios against the pull request's latest commit.

**3. The comment becomes the report**

It updates while the run goes, then shows a verdict per platform, the **Critical** and **Warning** scenarios with the criterion that failed, what was expected and what Mini observed, and a link to the full run in the dashboard.

**4. A new commit marks it stale**

Push again and the section shows **Stale**, with a **Re-run** box to test the new commit.

Only collaborators on the repository can start a run. If someone else ticks the box, Mini unticks it and asks them to ping a maintainer.

| Comment | What Mini does |
| - | - |
| `@mini test <app-slug>` | Runs the app's scenarios on the pull request's latest commit. |
| `@mini cancel <app-slug>` | Stops the run in progress. |
| `@mini help` | Lists these commands. |

### When Mini comments

Mini comments on a pull request when both are true:

* It targets the app's **default branch**, or a branch matching one of the app's **Release branches** patterns (gitignore-style globs, like `release/*`).
* For an app in a monorepo, at least one changed file sits under the app's **Source folder**.

The default branch and source folder are set when you [link the app to its repository](https://www.minitap.ai/docs/minitest/integrations/github.md#link-an-app-to-its-repository). Release branches live in the app's **Workbench → CI & Maintenance → Pull requests**. On any other pull request Mini stays quiet, and runs started by the GitHub Action still work.

## The check run

Every run started through GitHub, from the comment or from the GitHub Action, posts a check on its commit. The check is named after the app and still carries the product's former name:

```text theme={"theme":{"light":"github-light","dark":"vesper"}}
Minitest (Shop)
```

That's the name to look for in branch protection. A run started from **Run affected** in Mini's comment posts `Minitest (Shop) (affected)`: add that name too if your team runs affected scenarios from the comment.

* The check goes from queued to in progress to completed, with a success, failure, neutral or cancelled conclusion. A cancelled run always shows as cancelled.
* While it runs, and after a failure, it offers **Cancel** and **Bypass** buttons. **Bypass** keeps the check green even if the run later fails.

### Block merge on failing tests

The check is informational by default: a failing run gives a neutral conclusion and doesn't stop a merge. To make it a gate:

1. Turn on **Block merge on failing tests** in the app's **Workbench → CI & Maintenance → Pull requests**. A failing run now gives the check a failure conclusion. It applies to future runs.
2. In GitHub, add the check to the branch's required status checks in your branch protection rules.

This setting only changes the check's conclusion. To hold a deploy in a workflow instead, run the GitHub Action with `wait-for-result: true` and `fail-on-failure: true`: the step fails on a failing verdict and the jobs that depend on it are skipped. See [Blocking a release on the result](https://www.minitap.ai/docs/minitest/reference/minitest-trigger-action.md#blocking-a-release-on-the-result). The two work independently.

## Choosing what to run

From the comment, **Run affected** runs the scenarios Mini found the change affects, and `@mini test` runs the app's scenarios. From a workflow, the [GitHub Action](https://www.minitap.ai/docs/minitest/reference/minitest-trigger-action.md) chooses with its inputs:

| You want | Set | Runs |
| - | - | - |
| What this pull request affects | `scope: pr-affected` | The scenarios the pull request's changes could impact. Needs a pull request event and the Minitap GitHub App on the repository; otherwise the whole suite runs, with a warning. |
| What changed since the last release | `scope: affected` | On a tag matching the app's **Release tags** pattern, the scenarios affected since the previous matching tag. |
| Full regression | `scope: full` | Every scenario of the app. |
| A named set | `user-stories` or `user-story-types` | Only the scenarios you list. Takes precedence over `scope`. |

Leave `scope` empty and Minitap decides: affected on a matching release tag, the full suite otherwise.

```yaml theme={"theme":{"light":"github-light","dark":"vesper"}}
- uses: minitap-ai/minitest-trigger@v2
  with:
    app-slug: my-app
    scope: pr-affected
```

Set the **Release tags** pattern (a glob such as `v*` or `release-v*`) in the app's **Workbench → CI & Maintenance → Pull requests**. It only takes effect when your workflow runs the Action on tag pushes.

```yaml theme={"theme":{"light":"github-light","dark":"vesper"}}
on:
  push:
    tags: ['v*']
jobs:
  test:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: minitap-ai/minitest-trigger@v2
        with:
          app-slug: my-app
          scope: affected
```

> [!NOTE]
>
> Comments and checks on pull requests are GitHub only. On GitLab or Bitbucket, gate a pipeline with the CLI: see [CLI, for any CI](https://www.minitap.ai/docs/minitest/runs/triggering-a-run.md#cli-for-any-ci).

## Next steps

> [card] [Install the GitHub App](https://www.minitap.ai/docs/minitest/integrations/github.md)
>
> Connect your organization and link each app to its repository.

> [card] [GitHub Action reference](https://www.minitap.ai/docs/minitest/reference/minitest-trigger-action.md)
>
> Every input, build paths and web runs.

> [card] [Read the run report](https://www.minitap.ai/docs/minitest/runs/run-report.md)
>
> What each verdict means and how to act on a failure.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.