Skip to main content

​
Overview: Integrating your CI pipeline for mobile app testing

Before mobile test runs can execute, QA Wolf must enable mobile triggers for your workspace. This setup connects uploaded mobile builds to the correct environments and tests.

​
QA Wolf will handle this configuration and may ask you for:

  • Which environments you want to test.
  • Whether PR testing is enabled.
  • The artifact naming conventions you are using to confirm that it matches our criteria.
  • The upload and trigger method you chose
Until this step is complete, CI jobs can upload artifacts and send deployment notifications, but mobile test runs will not start automatically.

​
Available triggers

QA Wolf supports multiple methods for uploading mobile build artifacts and triggering test runs. Each option is designed to fit a different type of setup. The test coverage and results are the same—the difference is how well each option fits into your existing workflow.

​
Use the Fastlane plugin if:

  • You already use Fastlane to build Android or iOS apps
  • Your mobile builds and releases are defined as Fastlane lanes
  • You want artifact upload and test triggering to live alongside other mobile automation
  • Your team prefers mobile-specific tooling over general CI scripts
Fastlane is the natural fit for mobile teams and the recommended option when it is already part of your workflow.

​
Use the CI SDK if:

  • You do not use Fastlane
  • You want a single, consistent approach across mobile and web projects
  • Your CI environment is not based on GitHub Actions
  • You need more control over how artifacts are uploaded or when triggers fire
The CI SDK works with any CI system that supports Node.js, offering the greatest flexibility.

​
Use GitHub Actions if:

  • Your repository already uses GitHub Actions for CI
  • You want a minimal, declarative setup with prebuilt steps
  • Your build artifacts are already produced in a GitHub Actions workflow
GitHub Actions are a good fit for teams that want to stay entirely within GitHub.
Before mobile test runs can be triggered, your CI pipeline must produce a build artifact that QA Wolf can upload and use for testing.QA Wolf supports the following mobile artifact types:
  • Android: APK or AAB
  • iOS: IPA
The build does not need to be signed for store distribution, but it must be installable on test devices or emulators.

​
Build requirements:

To prepare a mobile build for QA Wolf testing:
  • Ensure your CI pipeline reliably produces a single build artifact per run.
  • Make the artifact available at a known file path during the CI job.
  • Rename the artifact to match the expected naming conventions before uploading.
  • Verify that the build completes successfully without requiring manual steps.

​
Environment-specific builds:

If you test against multiple environments, ensure the build matches the environment being tested:
  • Static environments (such as staging) should always produce artifacts with a consistent name.
  • PR or ephemeral environments should include identifying information (such as org, repo, and PR number) in the filename.
This allows QA Wolf to associate the correct build with the correct test environment, making debugging easier when issues arise.

​
What happens next:

Once your CI pipeline reliably produces a correctly named mobile artifact, you can upload it using one of the supported integration methods. Enabling artifact-based triggers on the QA Wolf platform is handled separately by the QA Wolf team.
Mobile build artifacts must follow consistent naming conventions so QA Wolf can correctly associate each build with the right environment and make failures easier to diagnose.The artifact name is used to identify:
  • Which environment the build belongs to
  • Whether the build is tied to a pull request
  • Which build was used for a given test run

​
Static environments:

Static environments are long-lived environments such as staging or release environments.Format
<prefix>-<environment-name>
Example
app-staging
Use the same basename every time a build is generated for the same environment.

​
PR (ephemeral) environments:

PR environments are short-lived and tied to a specific pull request. These are only relevant if PR testing is enabled.Format
<prefix>-<org>-<repo>-pr<number>
Example
app-myorg-myrepo-pr123
Including the organization, repository, and pull request number ensures each build can be traced back to the correct change and environment.
QA Wolf applies the file extension (.apk, .aab, or .ipa) automatically based on the uploaded artifact. You only need to provide the basename
Mobile test runs are triggered when a new mobile build is uploaded and a deployment event is sent to QA Wolf. This allows tests to run automatically against the specific build produced by your CI pipeline.

​
Triggering a run involves two parts:

  • Your CI pipeline builds the mobile artifact (APK, AAB, or IPA), uploads it, and sends a deployment notification.
  • QA Wolf platform configuration, which determines how uploaded artifacts are associated with environments and which tests should run.
On the customer side, the trigger is initiated by CI events such as a staging deploy, a release build, or a pull request build. On the QA Wolf side, the trigger must be enabled and configured for your workspace before mobile test runs will execute.Until that configuration is in place, CI jobs can still upload artifacts and send deployment notifications, but no test runs will start automatically.
Once mobile triggers are enabled and your CI pipeline is uploading artifacts correctly, mobile test runs will start automatically when the configured trigger event occurs.

​
When a trigger fires:

  • A new run is created for the environment associated with the uploaded mobile build.
  • Flows execute against the specific artifact produced by your CI pipeline.
  • Run results appear on the Runs tab, just like other QA Wolf runs.
If flows fail, the run enters an investigation state and can be reviewed using the same tools used for web testing, including videos, logs, and traces. From there, failures can be retried, fixed, bypassed, or handled as follow-up work, depending on the cause.Mobile triggers do not change how results are interpreted—they simply automate when runs start and ensure tests run against the correct mobile build.
Last modified on February 9, 2026