> ## 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. # Release gates > Decide which of Mini's verdicts stop a merge or a release, which scenarios run at each gate, and how to let a change through. 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](https://mintcdn.com/minitap-30239763/dKiS2PJCVmjStdUQ/minitest/images/app/workbench-ci.png?fit=max\&auto=format\&n=dKiS2PJCVmjStdUQ\&q=85\&s=7577123fe81e23025dba301c5f7edac9) 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](https://www.minitap.ai/docs/minitest/integrations/github.md#link-an-app-to-its-repository). | Setting | What it changes | | - | - | | **Block merge on failing tests** | A failing run gives the [PR check](https://www.minitap.ai/docs/minitest/runs/pull-request-checks.md#the-check-run) 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 1. Turn on **Block merge on failing tests**. 2. 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](https://www.minitap.ai/docs/minitest/reference/minitest-trigger-action.md) in the workflow that ships, and make the shipping job depend on it: ```yaml theme={"theme":{"light":"github-light","dark":"vesper"}} 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](https://www.minitap.ai/docs/minitest/reference/minitest-trigger-action.md#blocking-a-release-on-the-result) has every input and output; [Run in CI](https://www.minitap.ai/docs/minitest/runs/ci.md) 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](https://www.minitap.ai/docs/minitest/runs/pull-request-checks.md#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](https://www.minitap.ai/docs/minitest/runs/verdicts.md). 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 ` 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](https://www.minitap.ai/docs/minitest/get-started/how-mini-learns.md)). | ## Next steps > [card] [Pull request checks](https://www.minitap.ai/docs/minitest/runs/pull-request-checks.md) > > The comment, the check and the commands on each pull request. > [card] [GitHub Action reference](https://www.minitap.ai/docs/minitest/reference/minitest-trigger-action.md) > > Every input and output of the Action. > [card] [Run in CI](https://www.minitap.ai/docs/minitest/runs/ci.md) > > The same gate on GitLab, CircleCI, Bitbucket, Azure and Jenkins. > [card] [Verdicts and severity](https://www.minitap.ai/docs/minitest/runs/verdicts.md) > > What each verdict means and how to change Mini's call. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.