Skip to main content
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 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.

​
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. 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:
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. 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 chooses with its inputs: Leave scope empty and Minitap decides: affected on a matching release tag, the full suite otherwise.
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.
Comments and checks on pull requests are GitHub only. On GitLab or Bitbucket, gate a pipeline with the CLI: see CLI, for any CI.

​
Next steps

Install the GitHub App

Connect your organization and link each app to its repository.

GitHub Action reference

Every input, build paths and web runs.

Read the run report

What each verdict means and how to act on a failure.