Skip to main content
Run Revyl tests automatically on every pull request. This guide covers GitHub Actions, the Revyl CLI in CI, and integrating test results into your workflow.

Prerequisites

  • Revyl account with an API key
  • App and tests already created (see Your First Test)

Step 1: Store your API key

Add REVYL_API_KEY as a repository secret in GitHub: Settings → Secrets and variables → Actions → New repository secret Name: REVYL_API_KEY Value: your API key from Account → API Keys

Step 2: Add a workflow file

Option A: Run tests with saved choices

Run your workflow on every pull request with its saved choices. Tests saved on Default branch run on the pull request’s source branch when it has a usable build, otherwise on the app’s default branch. Tests created in the dashboard start on All branches · Latest build instead; see New saved choices, or use Option C.
The installer downloads the native CLI binary. The CLI exits with code 0 on pass, 1 on failure.

Option B: Build, upload, and test

Build your app fresh, upload the artifact, and run the full suite against it:
revyl workflow run <workflow> --build builds your app on the runner with the build settings in .revyl/config.yaml, uploads the artifact to the pull request’s source branch, and runs the workflow on that exact build. --platform chooses the platform to build; tests for other platforms keep their saved choices. Without --build, the workflow runs its saved choices, as in Option A.

Option C: Test an artifact from your own build job

After your CI build succeeds, upload its artifact and pass the returned build ID to the workflow, so the run tests that exact build. The upload goes to the pull request’s source branch; see Choose where CI uploads go.
For one test, use revyl test run "$TEST_ID" --build-id "$REVYL_BUILD_ID". Use an existing test for this app/platform. Runtime app overrides replace the workflow’s saved app configuration; unspecified platforms use each test’s saved choice. An exact Android override does not select an iOS build.

Option D: Use the Revyl GitHub Actions

Upload with upload-build, then run that build with run-test:
upload-build uploads to the pull request’s source branch unless you set branch. run-test and run-workflow follow the same branch rules as the CLI. See the Revyl GitHub Actions README for every input.

Step 3: Sync tests from CI

Keep remote tests in sync with your repo after merge to main:

CLI in CI (without GitHub Action)

Install and run the CLI directly in any CI:

Build upload from CI

See CI Builds for setup details.

Useful CI Patterns

Retries

Async execution

JSON output for downstream processing

Version-tagged builds

Pass both selectors in CI. No profile is stored as active/default, and a non-interactive build fails with the available choices if selection remains ambiguous.

Keep main or staging current

Pull request builds don’t refresh main or staging after merge. To keep a branch as your source of truth, upload each new build to it and run your tests on that build, explore it, or both, after every merge or on a schedule. See Keep a source-of-truth branch current.

GitLab CI

To test a merge request’s own build on GitLab, see Choose where CI uploads go.

Buildkite

Provide REVYL_API_KEY and REVYL_ANDROID_APP_ID as Buildkite secrets or environment variables. $$ defers each variable to run time.

CI-Friendly Flags

See CI-Friendly Flags.

Exit Codes

Environment Variables