Skip to main content
Run your repository’s Momentic tests in GitHub Actions (GHA). These workflows cover authentication, pull request gates, mobile builds, and sharding. More examples live in momentic-ai/examples. Given this root package.json:
package.json
Run npm install locally and commit package-lock.json with package.json. The workflows below use the lockfile for npm caching and reproducible dependency installation. Create a file called .github/workflows/ci.yml in your repository with the following contents:
ci.yml

Authentication

To run any commands, you must authenticate with Momentic. Add the MOMENTIC_API_KEY environment variable to your GitHub Actions workflow.
  1. Create an API key in the Momentic dashboard.
Create an API key in Momentic settings
Copy the value. You add it as a CI secret in the next step.
  1. Go to your GitHub repository settings and click Secrets, then Actions. Create a new secret called MOMENTIC_API_KEY and enter your API key.
GitHub repository secrets settings page
New Actions secret form
  1. At the top of your GitHub Actions workflow, provide the following environment variables to jobs that use momentic:
ci.yml

Gate a pull request from a coding agent

Pull requests opened by coding agents run through the same configured checks as other pull requests. The job below runs the repository’s YAML tests against their configured target. A counted failure returns a nonzero exit code; make the check required to block merging. Keep the gate small and strict. Label the flows whose failure should block a merge with critical, run only those on pull_request, and upload the results so the dashboard includes the failed step and its available artifacts:
.github/workflows/agent-gate.yml
  • --labels critical limits the gate to the labeled tests, so the gate runs a smaller set.
  • --reporter steps logs each step as it starts and finishes. An agent that reads the job log sees the step that failed without opening the dashboard.
  • --upload-results attaches the run to the dashboard, where the failed step includes the trace and any recorded video.
Add the check name (Agent gate / Critical flows) to the branch protection’s required status checks. Until then, the gate is advisory and an agent can merge over a failure. With the MCP server installed, you can ask the agent to run the affected tests locally and inspect failures before pushing. The CI job then validates the committed version. See Gate pull requests on critical flows for the label conventions and the flake policy.

Run mobile tests on a pull request

iOS and Android tests run with momentic-mobile, one workflow per platform. Remote simulators and emulators run on Momentic, so the test job needs no macOS runner and no Xcode. Only the build step needs macOS, because the iOS testing build is an .app bundle from Xcode. Upload the build once, then run the iOS tests against it:
.github/workflows/ios.yml
  • --channel pr --tag $ASSET_TAG installs the build this pull request produced, so the tests never run against a stale app. Tags are immutable: a (channel, tag) accepts only the same bytes again. A tag built from github.sha, github.run_id, and github.run_attempt is new on every run and every rerun, so a rebuilt app never collides with an earlier upload.
  • tests/ios limits the run to the iOS tests. Without a path or --include pattern, momentic-mobile run collects the Android tests too, and they fail because no APK exists under this channel and tag.
  • --parallel AUTO runs the tests at the same time. Each remote test gets its own simulator or emulator, so tests can run independently, subject to organization quotas and runner limits.
  • An Android build follows the same shape in its own workflow: build the APK on ubuntu-latest, upload it with assets upload, and run tests/android with the same --channel and --tag.
Local simulators and emulators on a CI runner boot slowly and, for iOS, allow one test at a time. Prefer remote simulators in CI. See Simulators and Emulators for the app requirements, and momentic-mobile assets for channels and tags.

Sharding

If you have a large test set, use sharding to run tests in parallel across CI jobs and shorten total run time. To shard your tests, pass the --shard-index and --shard-count options to the momentic run command. --shard-index is the index of the current shard (starting from 1), and --shard-count is the total number of shards. To collect test results inside a single run group in the Momentic dashboard, add a separate step after all tests complete to merge and upload results.
ci.yml