Favicon

You are here: Home > App Distribution > CI/CD > GitHub Actions

GitHub Actions

Learn how to integrate Applivery with GitHub Actions to automate mobile app distribution. Deploy iOS & Android builds seamlessly.

10 min read

TL;DR

Automate your mobile app distribution to Applivery using GitHub Actions, streamlining the deployment process for iOS and Android builds.

github

GitHub Actions is GitHub's built-in CI/CD platform. Pipelines are defined as YAML workflows stored directly in your repository under .github/workflows/, triggered by events such as pushes, pull requests, or manual runs.

The Applivery integration with GitHub Actions allows you to automatically upload a new build to Applivery at the end of each workflow run — making freshly built binaries immediately available to QA teams, stakeholders, or internal users without any manual steps.

There are two approaches to integrating GitHub Actions with Applivery:

  • Via Fastlane — recommended if your project already uses Fastlane for building and signing. A single lane call handles building and uploading.

  • Via the Applivery Upload API directly — recommended for any project or when Fastlane is not in use. Uses a curl step in your workflow YAML with no additional dependencies.


Prerequisites

Before setting up either approach, make sure you have:

  • A GitHub repository with Actions enabled.

  • An Applivery App API Token. Find it in App Settings → API Tokens in the Applivery Dashboard, or see Apps API Token.

  • A workflow that produces a build artifact (.ipa, .apk, .aab, or another supported format).


1
Store the App Token as a GitHub Secret

Never hardcode your Applivery token directly in a workflow file — it would be committed to your repository and visible to anyone with read access. Store it as a GitHub Secret so it is masked in logs and injected as an environment variable at runtime.

  1. Open your GitHub repository.

  2. Go to Settings → Secrets and variables → Actions.

  3. Click New repository secret.

  4. Set the name to APPLIVERY_TOKEN.

  5. Paste your Applivery App API Token as the value.

  6. Click Add secret.

Once saved, reference it in your workflow YAML as ${{ secrets.APPLIVERY_TOKEN }}.

Note

If multiple repositories need access to the same token, create an Organization secret instead. Go to your organization's Settings → Secrets and variables → Actions and follow the same process.

2
Option A — Integration via Fastlane

This approach is recommended if your project already uses Fastlane. The Applivery Fastlane plugin handles the upload and all metadata in a single lane call.

For full plugin documentation, see Fastlane Integration.

Workflow YAML

name: Build and deploy to Applivery

on:
  push:
    branches:
      - develop
      - main

jobs:
  deploy:
    runs-on: macos-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: '3.2'
          bundler-cache: true

      - name: Deploy to Applivery via Fastlane
        run: bundle exec fastlane ios deploy
        env:
          APPLIVERY_TOKEN: ${{ secrets.APPLIVERY_TOKEN }}

Fastfile

platform :ios do
  lane :deploy do
    gym(
      scheme: "MyApp",
      export_method: "enterprise"
    )

    applivery(
      app_token: ENV["APPLIVERY_TOKEN"],
      changelog: ENV["COMMIT_MESSAGE"],
      notify_collaborators: true,
      notify_message: "New build from GitHub Actions",
      tags: "github-actions, #{ENV["GITHUB_REF_NAME"]}"
    )
  end
end
3
Option B — Integration via the Upload API (without Fastlane)

This approach calls the Applivery Upload API directly from your workflow using curl. It works for any platform and requires no additional tooling.

iOS example

name: Build and deploy iOS to Applivery

on:
  push:
    branches:
      - develop

jobs:
  build-and-deploy:
    runs-on: macos-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Build iOS app
        run: |
          xcodebuild -scheme MyApp \
            -configuration Release \
            -archivePath build/MyApp.xcarchive \
            archive
          xcodebuild -exportArchive \
            -archivePath build/MyApp.xcarchive \
            -exportPath build/ \
            -exportOptionsPlist ExportOptions.plist

      - name: Upload to Applivery
        run: |
          curl 'https://upload.applivery.io/v1/integrations/builds' \
            --retry 5 \
            --fail \
            -H "Authorization: Bearer ${{ secrets.APPLIVERY_TOKEN }}" \
            -F "build=@build/MyApp.ipa" \
            -F "versionName=${{ github.run_number }}" \
            -F "changelog=${{ github.event.head_commit.message }}" \
            -F "tags=github-actions, ${{ github.ref_name }}" \
            -F "notifyCollaborators=true" \
            -F "notifyMessage=New iOS build from GitHub Actions" \
            -F "notifyLanguage=en" \
            -F "deployer.name=GitHub Actions" \
            -F "deployer.info.commit=${{ github.sha }}" \
            -F "deployer.info.branch=${{ github.ref_name }}" \
            -F "deployer.info.commitMessage=${{ github.event.head_commit.message }}" \
            -F "deployer.info.buildUrl=${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}" \
            -F "deployer.info.buildNumber=${{ github.run_number }}" \
            -F "deployer.info.repositoryUrl=${{ github.server_url }}/${{ github.repository }}"

Android example

name: Build and deploy Android to Applivery

on:
  push:
    branches:
      - develop

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up JDK
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'

      - name: Build Android APK
        run: ./gradlew assembleRelease

      - name: Upload to Applivery
        run: |
          curl 'https://upload.applivery.io/v1/integrations/builds' \
            --retry 5 \
            --fail \
            -H "Authorization: Bearer ${{ secrets.APPLIVERY_TOKEN }}" \
            -F "build=@app/build/outputs/apk/release/app-release.apk" \
            -F "versionName=${{ github.run_number }}" \
            -F "changelog=${{ github.event.head_commit.message }}" \
            -F "tags=github-actions, ${{ github.ref_name }}" \
            -F "notifyCollaborators=true" \
            -F "notifyMessage=New Android build from GitHub Actions" \
            -F "notifyLanguage=en" \
            -F "deployer.name=GitHub Actions" \
            -F "deployer.info.commit=${{ github.sha }}" \
            -F "deployer.info.branch=${{ github.ref_name }}" \
            -F "deployer.info.commitMessage=${{ github.event.head_commit.message }}" \
            -F "deployer.info.buildUrl=${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}" \
            -F "deployer.info.buildNumber=${{ github.run_number }}" \
            -F "deployer.info.repositoryUrl=${{ github.server_url }}/${{ github.repository }}"

Advanced: Trigger on tags for Release Builds

A common pattern is to trigger the Applivery upload only on version tags (e.g. v2.4.0), keeping feature branch builds separate from release candidates:

on:
  push:
    tags:
      - 'v*'   # Triggers on v1.0.0, v2.4.0-rc1, etc.

Combined with ${{ github.ref_name }} as a tag in Applivery, this makes it easy to filter release builds from the Dashboard.


Advanced: Upload only on successful tests

Use job dependencies to ensure the build is only uploaded to Applivery if tests pass:

jobs:
  test:
    runs-on: macos-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run tests
        run: ./gradlew test

  deploy:
    runs-on: ubuntu-latest
    needs: test   # Only runs if the 'test' job succeeds
    steps:
      - name: Upload to Applivery
        run: |
          curl ...

GitHub Actions Context Variables

The workflow examples above use GitHub Actions context variables that are automatically available in every workflow:

Variable

Description

${{ github.sha }}

Full SHA of the commit that triggered the workflow.

${{ github.ref_name }}

Short name of the branch or tag (e.g. develop, v2.4.0).

${{ github.run_number }}

Sequential run number for the workflow. Useful as a versionName in Applivery.

${{ github.run_id }}

Unique numeric ID for the workflow run. Used to construct the build URL.

${{ github.event.head_commit.message }}

Commit message of the commit that triggered the workflow. Useful as changelog.

${{ github.server_url }}

Base URL of the GitHub instance (e.g. https://github.com).

${{ github.repository }}

Owner and repository name (e.g. myorg/myapp).

${{ secrets.APPLIVERY_TOKEN }}

The Applivery App Token stored as a GitHub Secret.

For the full reference, see the GitHub Actions context documentation.


Key upload parameters reference

The curl form fields map directly to the Applivery Upload API. The most commonly used parameters:

Parameter

Description

build

The binary file to upload (.ipa, .apk, .aab).

versionName

Human-readable label for the build. Using ${{ github.run_number }} links it to the GitHub run.

changelog

Release notes shown in the Dashboard and notification emails.

tags

Comma-separated tags for filtering builds. E.g. github-actions, develop.

notifyCollaborators

Set to true to email app collaborators on upload.

notifyMessage

Custom message included in the notification email.

deployer.name

CI platform name shown in the Applivery Dashboard.

deployer.info.commit

Git commit SHA.

deployer.info.branch

Git branch or tag name.

deployer.info.buildNumber

Workflow run number.

deployer.info.buildUrl

Direct URL to the GitHub Actions workflow run.

For the complete parameter reference, see POST – Upload a Build.

Key Takeaways

  • Automate app distribution with GitHub Actions and Applivery.
  • Securely store your Applivery API token as a GitHub Secret.
  • Choose between Fastlane or direct API integration based on your project setup.
  • Use GitHub Actions context variables to pass build information to Applivery.
  • Trigger uploads based on tags or successful test runs for release management.