Triggering a run

A run takes your suite (or part of it) and runs it against a build on virtual devices. There are four ways to start one; pick whichever fits how you work.

From the dashboard
From Slack
From CI
From the CLI

Click Run tests on any app page. A side panel walks you through two steps:

Pick a build. Use the latest build for the configured branch, pick a specific commit or build ID, upload a fresh .apk / .ipa, or paste a PWA URL.
Pick the stories. Run all of them (default) or narrow to a subset from a searchable list.

Click Start run and Mini queues it on the next available device. The dashboard’s Runs tab updates live.Best for one-off checks before a demo, validating a fix you just pushed, or sanity-checking a build that came in from a third-party CI.

There are two ways to do it, both through @mini. There’s no slash command.Type the run inline. Mention Mini with the app and the build tag:

@mini run acme-checkout v1.4.2

Mini posts an ephemeral confirm with a 10-second cancel window, then fires. The heartbeat lands in the channel you configured for that app (see Channel routing).Or open the picker. For a guided flow:

@mini run all tests

Mini posts an interactive message walking you through app → build → stories → confirm.

Triggering from Slack requires your Slack user to be linked to a Minitap account. See Linking your account.

The path that powers PR checks. Set this up once and Mini runs your suite on every PR: it builds the head commit, runs the stories, and posts the verdict back on the PR.Setup is a workflow file in your repo that calls the minitap-ai/minitest-trigger GitHub Action. The Action uploads the build (or asks Mini to build one) and starts the run, authenticated by the workflow’s GitHub OIDC token, so there’s no API key to manage.

.github/workflows/minitest.yml

name: miniTest

on:
  pull_request:
    branches: [main]

jobs:
  run-suite:
    runs-on: ubuntu-latest
    permissions:
      id-token: write   # required for OIDC auth
      contents: read
    steps:
      - uses: minitap-ai/minitest-trigger@v1
        with:
          app-slug: my-app

Drop that file in .github/workflows/, push it to your default branch, and you’re done. The MiniTest GitHub App (see GitHub integration) must already be installed on the org. That’s what lets Mini post the verdict back to the PR.

The default config builds the head commit, runs every story, and posts a check + sticky comment on the PR. For every input (run-ios, run-android, ios-build-path, android-build-path, user-story-types, tenant-id, cancel-previous-runs), see GitHub Action reference.

Required vs informational

The PR check is informational by default. There are two independent ways to make a bad verdict actually stop something, and they block different things.Block the merge. Turn on Block merge on failing tests in App Settings → Maintenance → Pull requests and add the check to GitHub → Settings → Branches → Branch protection rules → Require status checks. The setting flips the check run’s conclusion from neutral to failure, which is what branch protection reads.Block the workflow. Put the Action in its own job with wait-for-result: true and fail-on-failure: true, then hang the jobs you want gated off it:

jobs:
  minitest-gate:
    runs-on: ubuntu-latest
    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

  deploy:
    needs: minitest-gate
    runs-on: ubuntu-latest
    steps:
      - run: ./deploy.sh

The step waits for the verdict and fails on a failure, so deploy is skipped. This is the one you want for a release gate, where the thing to hold back is the deploy rather than a merge. It works with block_on_test_failures left off. See Blocking a release on the result for timeouts and the nothing_affected case.For everything the GitHub App posts on a PR (the sticky comment, the check run, the checkbox and slash-command triggers), see GitHub integration.

Re-running

Toggle the Run tests checkbox in the sticky PR comment.
Or post /test as a PR comment.
Or click Re-run on the dashboard run report.

Two commands, depending on scope.One story:

minitest run start <user-story-id> \
  --ios-build <build-id> \
  --android-build <build-id>

The whole suite:

minitest run all \
  --ios-build <build-id> \
  --android-build <build-id>

Both accept --watch to stream status to your terminal instead of printing the run ID and exiting. Sign in with minitest auth login once. See the CLI reference for everything else.

Native cloud device type (pending)

Coming soon. Native cloud tablet selection is not deployed. It is pending behind native-tablets, off by default; the contract below is not a publicly available feature.

For native cloud iOS and Android targets, the pending contract adds optional deviceType: "phone" | "tablet". Omit it for effective phone execution; existing phone labels stay unchanged. Select one form factor per platform per run. To compare phone and tablet on the same platform, use separate runs. Explicit deviceType, including phone, is rejected on web, mobile-web, physical-device, and edge-device targets. Web defaults and browser/viewport targets keep their existing meaning; they do not select native tablets. See the pending CLI flags and GitHub Action inputs, and the tablet compatibility limits. See Reading a run report for what to do with the result.

Get started

Your suite

Run your suite

Integrations

Reference

Required vs informational

Re-running

Native cloud device type (pending)

​Required vs informational

​Re-running

​Native cloud device type (pending)

Required vs informational

Re-running

Native cloud device type (pending)