Skip to main content
Integrate Autosana into your CI/CD pipeline with our GitHub Action to automatically upload and test your builds with every commit. Supports iOS, Android, web, and Chrome-extension platforms.
Autosana GitHub Action uploading a build
Add our MCP Server to help with setting up your CI/CD pipeline.

Step 1: Choose Your Platform

Select your platform to see the relevant setup instructions:

iOS / Android

Mobile app builds (Expo, Fastlane, native)

Web

Web apps (Vercel, Netlify, custom deployments, etc.)

Chrome Extension

Manifest V3 extension zip builds

Mobile Setup

Choose Your Build Tool

Expo EAS

React Native with Expo’s build service

Fastlane

Native iOS/Android builds with Fastlane

Other

Gradle, Flutter, or custom builds

Step 2: Set Secrets

Go to your repository Settings → Secrets → Actions and add these secrets. See the GitHub Secrets docs for help.

Required for All

string
required
Your Autosana API key for uploading builds. Create and manage it in Settings → API Keys.

Required for Expo EAS

string
Your Expo access token for EAS builds. Get it from Expo account settings.

Step 3: Set up your Github Workflow with the Autosana Github Action

Create a .github/workflows/autosana-ios.yml and/or .github/workflows/autosana-android.yml file in your repository. Examples are provided below to get started.
For more specific build instructions by framework, check out our App Build Guide for detailed instructions on creating builds for iOS and Android.
Add this step to your existing GitHub workflow after your build step:
Required Parameters:
  • api-key: Your Autosana API key (from secrets)
  • bundle-id: Your app’s bundle ID (e.g., com.company.app)
  • platform: Either ios or android
  • build-path: Path to your build artifact
Optional Parameters:
  • name: Display name for your app (e.g., “My iOS App”). Updates existing app name if different.
  • labels: Comma-separated label names to run after upload (e.g., smoke,critical). Runs every suite and flow carrying any of the labels — resolved at run time, so CI config never changes as coverage grows. See Labels API.
  • suite-ids: Comma-separated suite UUIDs to run after upload (e.g., uuid1,uuid2).
  • flow-ids: Comma-separated flow UUIDs to run after upload (e.g., uuid1,uuid2).
  • suite-keys: Comma-separated code-managed suite keys to run from the checked-out commit.
  • flow-keys: Comma-separated code-managed flow keys to run from the checked-out commit.
  • environment: Name of the environment to associate this app with (e.g., staging, production). See Using Environments below.
  • variables: Key-value variables to attach to the uploaded build. Available in flow instructions via ${env:KEY}. Use KEY1=VALUE1,KEY2=VALUE2. See Build Variables.
  • physical-device: Mobile runs only. Set to true to use real hardware; defaults to false.
  • device-model: Single-device mobile runs only. Model from the Autosana device catalog, such as Pixel 10 Pro, or latest.
  • os-version: Single-device mobile runs only. OS version supported by the selected model, such as 17, or latest.
  • devices: Multi-device mobile runs only. JSON array of ordered device selections. Two-device flows currently require exactly two objects.
  • dependencies: For direct web runs only, a JSON array overriding the web app’s default Chrome extension loadout. Omit it to inherit defaults, use '[]' for no extensions, or provide extension app UUIDs and optional build pins. Requires suite-ids, flow-ids, flow-keys, or labels. It cannot be combined with suite-keys.
  • wait: Whether to wait for selected tests and fail the job when they fail. Defaults to true; set it to false for fire-and-forget runs.
  • enable-ios-keychain-access-group-remapping: iOS .ipa only. Set to true if cloud re-signing breaks Team-ID-prefixed Keychain access groups. The preference is saved on the app, so future IPA uploads can omit it; set it to false to disable.

Run code-managed tests by key

Use stable YAML keys instead of Autosana UUIDs when your flows and suites are managed in code. The Action resolves each key from the exact checked-out commit:
You can combine flow-keys with suite-keys. Do not combine key selectors with flow-ids, suite-ids, or labels.

Select a mobile device

Device inputs apply when any flow, suite, or label selector triggers tests. Use latest to make rolling model and OS selection explicit:
You can pin either field while leaving the other on latest, or pin both to a supported catalog combination:
Omitting device-model and os-version keeps the same rolling-Latest behavior. For the latest available real device, set physical-device: true and use latest (or omission) for the model and OS.

Github Action Workflow Examples

Configure eas.json

Add this profile to your eas.json for iOS simulator builds:
eas.json

GitHub Workflow

Important: Replace YOUR_BUNDLE_ID with your app’s bundle ID.
.github/workflows/autosana-eas-ios.yml

Chrome Extension Setup

Build or package the unpacked Manifest V3 extension directory as a .zip, then upload it like a mobile build:
The first upload creates the extension; later uploads with the same bundle-id create new versions and make the newest build active. Extension apps are organization-wide and do not use environment. The zip must contain manifest.json at its root or inside one top-level folder. Only Manifest V3 is supported. Limits are 500MB compressed, 2GB expanded, and 25,000 entries. After upload, attach the extension to a web app in the Autosana Apps page. CI-triggered tests inherit that app’s default extensions.
Chrome extension upload steps cannot trigger tests directly. Do not add flow, suite, or label selectors to a platform: chrome-extension step. Upload and attach the extension first, then run tests in a separate platform: web Action step using the web app’s default extensions or a dependencies override.

Web Setup

For web applications, you can register a URL (such as a preview deployment) for testing. This is useful for testing Vercel, Netlify, or other preview deployments on every PR.

Parameters

Required Parameters for Web:
  • api-key: Your Autosana API key (from secrets)
  • platform: Must be web
  • app-id: A unique identifier for your web app (lowercase, alphanumeric with hyphens, e.g., my-web-app)
  • url: The URL to test (e.g., your preview deployment URL)
Optional Parameters:
  • name: Display name for your web app (e.g., “My Web App”). Updates existing app name if different.
  • labels: Comma-separated label names to run after upload (e.g., smoke,critical). Runs every suite and flow carrying any of the labels — resolved at run time, so CI config never changes as coverage grows. See Labels API.
  • suite-ids: Comma-separated suite UUIDs to run after upload (e.g., uuid1,uuid2).
  • flow-ids: Comma-separated flow UUIDs to run after upload (e.g., uuid1,uuid2).
  • suite-keys: Comma-separated code-managed suite keys to run from the checked-out commit.
  • flow-keys: Comma-separated code-managed flow keys to run from the checked-out commit.
  • environment: Name of the environment to associate this app with (e.g., staging, production). See Using Environments below.
  • variables: Key-value variables to attach to the registered build. Available in flow instructions via ${env:KEY}. Use KEY1=VALUE1,KEY2=VALUE2. See Build Variables.

Basic Usage

Override Chrome Extensions for a Web Run

The dependencies input controls the extension loadout for tests triggered directly by this Action. It supports ID selectors, labels, and flow-keys, but cannot currently be combined with suite-keys:
Each string is an extension app UUID. Object entries use app_id and may add app_build_id to pin an exact build. The input must be a valid JSON array and is rejected for iOS, Android, and Chrome extension uploads.

Web Workflow Examples

For Vercel deployments using the GitHub integration (OAuth), use the wait-for-vercel-preview action to get the preview URL:
.github/workflows/autosana-web-vercel.yml
The wait-for-vercel-preview action requires the permissions block shown above to access deployment information. Without these permissions, you may see “Resource not accessible by integration” errors.
The app-id must be lowercase alphanumeric with hyphens only (e.g., my-web-app, staging, preview-app-123). This identifier is used to track your web app across deployments.

Step 4: What Happens Next?

Once you’ve set up our CI/CD integration:
1

Run flows directly (optional)

Add a flow, suite, or label selector to your action config to trigger tests immediately after upload. For code-managed tests, use flow-keys or suite-keys so the workflow keeps stable YAML identifiers instead of Autosana UUIDs. The Action waits for all tests to complete and reports results inline, failing the job if any test fails.
2

Configure automations

Alternatively (or additionally), set when flows run in your Automations page to run flows on a schedule or trigger.
3

View test results

Check your test runs in the Runs page.

Need Help Setting Up?

If you’re using Claude Code or another AI agent, you can add our MCP server to help automate the setup process. The MCP server can:
  • Set up your CI/CD pipeline automatically
  • Build your app for iOS or Android
  • Find your app’s bundle ID
  • And more!
Learn more at our MCP Server documentation.

Instructions for AI Agents Using the Autosana MCP (humans, you can ignore this!)

If you are an AI agent (such as Claude Code, Cline, or Cursor) using the Autosana MCP server to help set up CI/CD workflows, use the following prompt to guide your workflow generation.

Helpful Resources

App Build Guide

Learn how to build your app for our cloud

GitHub Action

View the source code and documentation for our GitHub Action

Get Your API Key

Copy your API key from Settings → Integrations

Commit detection and PR results

For deployment and deployment_status events, the action automatically uses the deployed commit, even when the workflow checks out trusted code. PR events continue to use the PR head SHA; other events retain checkout-based detection. For manual or scheduled workflows targeting a different commit from the checkout, pass commit-sha explicitly. Optional branch-name and repo-full-name inputs override the corresponding GitHub metadata. Web tests use the build returned by registration, keeping concurrent preview runs separate. The action reports its result through the workflow job. To show that result on a different PR, the calling workflow must create and complete a check on the PR’s head SHA with checks: write permission.