Prerequisites
- Revyl account with an API key
- App and tests already created (see Your First Test)
Step 1: Store your API key
AddREVYL_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.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.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 withupload-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
Useful CI Patterns
Retries
Async execution
JSON output for downstream processing
Version-tagged builds
Keep main or staging current
Pull request builds don’t refreshmain 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
Buildkite
REVYL_API_KEY and REVYL_ANDROID_APP_ID as Buildkite secrets or
environment variables. $$ defers each variable to run time.