Release gates

This page helps you decide what Mini’s verdicts are allowed to stop: a pull request merge, a release, or both. It covers the two gates Minitap gives you, which scenarios run at each one, and exactly which outcomes close the gate.

Gate	What it stops	Turn it on
Merge gate	Merging a pull request on GitHub	Block merge on failing tests, plus the check in your branch protection rules
Release gate	The jobs that come after it in a workflow, like a deploy or a store upload	The GitHub Action with `wait-for-result: true` and `fail-on-failure: true`

The two are independent. Use one, or both on the same repository: a check that blocks merges into main, and a workflow that blocks the deploy on each release tag.

Workbench, CI & Maintenance tab: Block merge on failing tests, Release tags, Release branches, and Fix test scenarios without asking — Workbench → CI & Maintenance holds both gates.

The settings

All three live in the app’s Workbench → CI & Maintenance, in the Pull requests group. The group shows once the app is linked to its GitHub repository.

Setting	What it changes
Block merge on failing tests	A failing run gives the PR check a failure conclusion instead of a neutral one. Off by default. Applies to runs that finish after you turn it on.
Release tags	A glob such as `v` or `release-v`. A tag that matches it runs only the scenarios affected since the previous matching tag. Empty, tag runs test the whole suite.
Release branches	Globs such as `release/*`. Pull requests into these branches, and into the default branch, get Mini’s comment. A new Action run on one of these branches cancels the older runs the Action started there and that are still going (`cancel-previous-runs`, on by default).

The toggle saves as soon as you flip it. Release tags and Release branches save together with Save.

Gate a merge

Turn on Block merge on failing tests.
In GitHub, add Mini’s check to the branch’s required status checks. The check is named after the app and still carries the product’s former name: Minitest (Shop). A run started from Run affected in Mini’s pull request comment posts Minitest (Shop) (affected), so add that name too if your team runs affected scenarios from the comment.

What the check ends with:

Run outcome	Toggle off	Toggle on
No scenario failed and at least one passed	success	success
A scenario failed, or the run failed as a whole (for example, the build failed)	neutral	failure
The run was cancelled	cancelled	cancelled
A newer commit replaced the run while it was going	neutral	neutral
No scenario passed or failed	neutral	neutral

Only a failure conclusion stops a merge, and only when the check is required.

Gate a release

Run the GitHub Action in the workflow that ships, and make the shipping job depend on it:

on:
  push:
    tags: ['v*']

jobs:
  minitap-gate:
    runs-on: ubuntu-latest
    timeout-minutes: 70
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: minitap-ai/minitest-trigger@v2
        with:
          app-slug: my-app
          wait-for-result: true
          fail-on-failure: true
          wait-timeout-minutes: 60

  release:
    needs: minitap-gate
    runs-on: ubuntu-latest
    steps:
      - run: ./release.sh

The step reads the run’s verdict straight from Minitap, so Block merge on failing tests has no effect on it, and Bypass on the GitHub check doesn’t open it. To watch the verdicts as warnings before they block anything, leave fail-on-failure off at first. The Action reference has every input and output; Run in CI has the same gate for GitLab, CircleCI and other pipelines.

Choose what runs at each gate

A gate is only as useful as the scenarios behind it. Pick the scope that matches the moment:

Moment	Set	What runs
A pull request	`scope: pr-affected`	The scenarios the pull request’s changes could impact. If none is affected, no run starts and the gate passes with `nothing_affected`.
A release tag	Release tags pattern, `scope` left empty	The scenarios affected since the previous release tag
Before a big release	`scope: full`	The whole suite
A smoke gate	`user-story-types: smoke`	Every scenario carrying one of the listed tags

For a release tag, the previous release is the nearest earlier tag matching the pattern in the commit history, whatever its name sorts as. On the first matching tag there is nothing to compare with, so Mini analyses the whole codebase. If the analysis finds no affected scenario, the gate passes with nothing_affected; if the analysis itself fails, the result is error. All options are in Choosing what to run.

What closes the gate

Both gates read the same outcomes, per scenario and per platform:

Outcome	Gate
Passed	Open
Warning	Open, as long as at least one scenario passed
Critical	Closed
Errored, or a Build failed	Closed
A scenario that didn’t run because a secret it needs has no value	Closed, and the scenario is named
Escalated, still waiting for an answer	The gate waits, unless the scenario is already graded Critical
The run was cancelled	Closed for the Action (`error`)

A run where no scenario passed and none failed, for example one with only Warnings, gives the Action error and the check a neutral conclusion. The verdicts themselves are explained in Verdicts and severity. While an escalated scenario waits, the check stays in progress with “Awaiting N escalated scenarios”, and the Action keeps waiting until wait-timeout-minutes. The gate settles once every escalated scenario is resolved.

Let a change through

You want	Do
Merge despite a red check	Click Bypass on the check in GitHub. The check turns green and says who bypassed it. The run keeps its verdict in the dashboard.
Stop a run that is no longer needed	Cancel on the check, or `@mini cancel <app-slug>` on the pull request
Test the fix	Push again. A run still going on the old commit closes its check as neutral, and the new commit gets its own run, from your workflow or from Re-run in Mini’s comment.
Clear a failed release gate	Fix the app, then re-run the workflow job. A false alarm you mark Not a bug doesn’t come back on the next run (How Mini learns).

Next steps

Pull request checks

The comment, the check and the commands on each pull request.

GitHub Action reference

Every input and output of the Action.

Run in CI

The same gate on GitLab, CircleCI, Bitbucket, Azure and Jenkins.

Verdicts and severity

What each verdict means and how to change Mini’s call.

Get started

Set up your app

Build your suite

Run

Review results

Integrations

Workspace and security

Troubleshooting

Reference

The settings

Gate a merge

Gate a release

Choose what runs at each gate

What closes the gate

Let a change through

Next steps

Pull request checks

GitHub Action reference

Run in CI

Verdicts and severity

​The settings

​Gate a merge

​Gate a release

​Choose what runs at each gate

​What closes the gate

​Let a change through

​Next steps

Pull request checks

GitHub Action reference

Run in CI

Verdicts and severity

The settings

Gate a merge

Gate a release

Choose what runs at each gate

What closes the gate

Let a change through

Next steps