Automate Mobile CI/CD with GitHub Actions and Source Push

Manual mobile releases are slow, error-prone, and hard to scale—especially when your team supports multiple apps, channels, and environments.

In this guide, you’ll build a practical CI/CD pipeline using GitHub Actions + Source Push so OTA updates become predictable, auditable, and fast.

Why automate OTA delivery?

When releases depend on local machines, teams often face:

• Inconsistent environments
• Credential sprawl
• Missing release history
• Slow rollback and promotion workflows

A GitHub Actions pipeline solves this by centralizing execution and secrets, while Source Push handles channel-based delivery.

What we’re building

A pipeline with three stages:

1. Validate: run tests/lint checks.
2. Release to Staging: publish OTA update to a staging channel.
3. Promote to Production: manually approve promotion when validation succeeds.

This gives you speed and control.

Prerequisites

Before you start, make sure you have:

• A React Native project configured for Source Push
• Source Push app/channels created (for example: Staging, Production)
• A CI token stored in GitHub Secrets (for example: SOURCE_PUSH_TOKEN)
• Optional: app name in secrets (SOURCE_PUSH_APP)

Step 1: Add CI secrets in GitHub

In your GitHub repository, go to Settings → Secrets and variables → Actions, and add:

• SOURCE_PUSH_TOKEN: token for Source Push CLI authentication
• SOURCE_PUSH_APP: Source Push app identifier (optional but recommended)

Keep channel names as workflow inputs or repository variables so they’re easier to change later.

Step 2: Create the GitHub Actions workflow

Create .github/workflows/mobile-ota.yml:

name: Mobile OTA CI/CD

on:
  workflow_dispatch:
    inputs:
      target_channel:
        description: "Target release channel"
        required: true
        default: "Staging"
      description:
        description: "Release notes"
        required: true
        default: "OTA update from CI"

jobs:
  validate:
    name: Validate
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Run tests
        run: npm test -- --passWithNoTests

  release_staging:
    name: Release OTA
    runs-on: ubuntu-latest
    needs: validate
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Install Source Push CLI
        run: npm install -g source-push-cli

      - name: Source Push Login
        run: srcpush login --token "${{ secrets.SOURCE_PUSH_TOKEN }}"

      - name: Release React Native OTA
        run: |
          srcpush release-react "${{ secrets.SOURCE_PUSH_APP }}" \
            --deployment "${{ github.event.inputs.target_channel }}" \
            --description "${{ github.event.inputs.description }}"

  promote_production:
    name: Promote to Production
    runs-on: ubuntu-latest
    needs: release_staging
    if: ${{ github.event.inputs.target_channel == 'Staging' }}
    environment: production
    steps:
      - name: Install Source Push CLI
        run: npm install -g source-push-cli

      - name: Source Push Login
        run: srcpush login --token "${{ secrets.SOURCE_PUSH_TOKEN }}"

      - name: Promote Staging to Production
        run: |
          srcpush promote "${{ secrets.SOURCE_PUSH_APP }}" Staging Production

Step 3: Protect production with environment approvals

Use GitHub Environments so production promotion requires explicit approval:

1. Go to Settings → Environments → New environment
2. Create production
3. Add required reviewers
4. (Optional) Add environment-scoped secrets

Now your pipeline can auto-release to staging while keeping a human checkpoint for production.

Step 4: Add branch-based automation (optional)

You can trigger staging releases on main pushes and keep production as manual approval:

on:
  push:
    branches: [main]
  workflow_dispatch:

A common pattern:

• push to main → release to Staging
• Manual approval in production environment → promote to Production

Operational best practices

To make this reliable at scale:

• Use small, frequent OTA updates
• Include clear release descriptions tied to commit SHA
• Keep rollback commands documented and tested
• Restrict token scope and rotate credentials
• Track adoption/health metrics before production promotion

Fast rollback pattern

If production metrics degrade, rollback should be one command away:

srcpush rollback MyApp Production

You can also automate rollback by integrating monitoring alerts into a follow-up workflow.

Final thoughts

CI/CD for mobile OTA updates is less about “more tooling” and more about reducing operational risk.

With GitHub Actions and Source Push, your team gets:

• Repeatable releases
• Better governance
• Faster incident response
• A deploy process that scales as your app portfolio grows

Start with one app and two channels (Staging and Production). Once stable, templatize the workflow and roll it out across every mobile project.