Favicon

You are here: Home > Distribución de Apps > CI/CD > GitHub Actions

GitHub Actions

Integra Applivery con GitHub Actions para automatizar la distribución de apps móviles.

10 min read

TL;DR

Automatiza la distribución de tus apps móviles a Applivery usando GitHub Actions, simplificando el proceso de despliegue.

github

GitHub Actions es la plataforma CI/CD integrada de GitHub. Los pipelines se definen como workflows YAML almacenados directamente en tu repositorio bajo .github/workflows/, y se disparan por eventos como pushes, pull requests o ejecuciones manuales.

La integración de Applivery con GitHub Actions te permite subir automáticamente una nueva Build a Applivery al final de cada ejecución del workflow, haciendo que los binarios recién compilados estén inmediatamente disponibles para los equipos de QA, las partes interesadas o los usuarios internos sin ningún paso manual.

Hay dos enfoques para integrar GitHub Actions con Applivery:

  • Mediante Fastlane — recomendado si tu proyecto ya usa Fastlane para compilar y firmar. Una sola llamada al lane gestiona la compilación y la subida.

  • Mediante la API de subida de Applivery directamente — recomendado para cualquier proyecto o cuando no se usa Fastlane. Usa un paso curl en tu workflow YAML sin dependencias adicionales.


Requisitos previos

Antes de configurar cualquiera de los dos enfoques, asegúrate de tener:

  • Un repositorio de GitHub con Actions activado.

  • Un App API Token de Applivery. Encuéntralo en Ajustes de la App → Token API en el panel de Applivery, o consulta Apps API Token.

  • Un workflow que genere un artefacto de Build (.ipa, .apk, .aab u otro formato compatible).


1
Guardar el App Token como GitHub Secret

Nunca escribas tu token de Applivery directamente en un archivo de workflow: quedaría en tu repositorio y sería visible para cualquiera con acceso de lectura. Guárdalo como GitHub Secret para que quede enmascarado en los logs e inyectado como variable de entorno en tiempo de ejecución.

  1. Abre tu repositorio de GitHub.

  2. Ve a Settings → Secrets and variables → Actions.

  3. Haz clic en New repository secret.

  4. Establece el nombre como APPLIVERY_TOKEN.

  5. Pega tu App API Token de Applivery como valor.

  6. Haz clic en Add secret.

Una vez guardado, referéncialo en tu workflow YAML como ${{ secrets.APPLIVERY_TOKEN }}.

Note

Si varios repositorios necesitan acceso al mismo token, crea un Organization secret en su lugar. Ve a Settings → Secrets and variables → Actions de tu organización y sigue el mismo proceso.

2
Opción A — Integración mediante Fastlane

Este enfoque es el recomendado si tu proyecto ya usa Fastlane. El plugin de Applivery para Fastlane gestiona la subida y todos los metadatos en una sola llamada al lane.

Para la documentación completa del plugin, consulta Integración con Fastlane.

Workflow YAML

name: Compilar y desplegar en Applivery

on:
  push:
    branches:
      - develop
      - main

jobs:
  deploy:
    runs-on: macos-latest

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

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

      - name: Desplegar en Applivery mediante 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: "Nueva Build desde GitHub Actions",
      tags: "github-actions, #{ENV["GITHUB_REF_NAME"]}"
    )
  end
end
3
Opción B — Integración mediante la API de subida (sin Fastlane)

Este enfoque llama directamente a la API de subida de Applivery desde tu workflow usando curl. Funciona para cualquier plataforma sin herramientas adicionales.

Ejemplo iOS

name: Compilar y desplegar iOS en Applivery

on:
  push:
    branches:
      - develop

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

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

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

      - name: Subir a 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=Nueva Build de iOS desde GitHub Actions" \
            -F "notifyLanguage=es" \
            -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 }}"

Ejemplo Android

name: Compilar y desplegar Android en Applivery

on:
  push:
    branches:
      - develop

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

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

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

      - name: Compilar APK de Android
        run: ./gradlew assembleRelease

      - name: Subir a 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=Nueva Build de Android desde GitHub Actions" \
            -F "notifyLanguage=es" \
            -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 }}"

Avanzado: Disparar por tags para Builds de release

Un patrón habitual es disparar la subida a Applivery solo con tags de versión (por ejemplo, v2.4.0), manteniendo las Builds de ramas de funcionalidades separadas de los candidatos a release:

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

Combinado con ${{ github.ref_name }} como tag en Applivery, es fácil filtrar Builds de release desde el panel.


Avanzado: Subir solo tras pruebas exitosas

Usa dependencias entre jobs para garantizar que la Build solo se sube a Applivery si las pruebas pasan:

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

  deploy:
    runs-on: ubuntu-latest
    needs: test   # Solo se ejecuta si el job 'test' tiene éxito
    steps:
      - name: Subir a Applivery
        run: |
          curl ...

Variables de contexto de GitHub Actions

Los ejemplos de workflow anteriores usan variables de contexto de GitHub Actions, disponibles automáticamente en cualquier workflow:

Variable Descripción
${{ github.sha }} SHA completo del commit que disparó el workflow.
${{ github.ref_name }} Nombre corto de la rama o tag (por ejemplo: develop, v2.4.0).
${{ github.run_number }} Número de ejecución secuencial del workflow. Útil como versionName en Applivery.
${{ github.run_id }} ID numérico único para la ejecución del workflow. Se usa para construir la URL de la Build.
${{ github.event.head_commit.message }} Mensaje del commit que disparó el workflow. Útil como changelog.
${{ github.server_url }} URL base de la instancia de GitHub (por ejemplo: https://github.com).
${{ github.repository }} Nombre del propietario y del repositorio (por ejemplo: miorg/miapp).
${{ secrets.APPLIVERY_TOKEN }} El App Token de Applivery guardado como GitHub Secret.

Para la referencia completa, consulta la documentación de contextos de GitHub Actions.


Referencia de parámetros de subida

Los campos del formulario curl se corresponden directamente con los parámetros de la API de subida de Applivery. Los más utilizados:

Parámetro Descripción
build El archivo binario a subir (.ipa, .apk, .aab).
versionName Etiqueta legible para la Build. Usar ${{ github.run_number }} la vincula con la ejecución de GitHub.
changelog Notas de la versión mostradas en el panel y en los emails de notificación.
tags Etiquetas separadas por comas para filtrar Builds. Por ejemplo: github-actions, develop.
notifyCollaborators Establece como true para enviar un email a los Colaboradores de la App al subir.
notifyMessage Mensaje personalizado incluido en el email de notificación.
deployer.name Nombre de la plataforma CI mostrado en el panel de Applivery.
deployer.info.commit SHA del commit de Git.
deployer.info.branch Rama o tag de Git.
deployer.info.buildNumber Número de ejecución del workflow.
deployer.info.buildUrl URL directa a la ejecución del workflow de GitHub Actions.

Para la referencia completa de parámetros, consulta POST – Subir una Build.

Puedes integrar Applivery con GitHub Actions usando Fastlane o llamando directamente a la API de subida de Applivery en tu workflow YAML.

Necesitas un repositorio de GitHub con Actions activado, un App API Token de Applivery y un workflow que genere un artefacto de Build (.ipa, .apk, .aab, etc.).

Guarda tu token de Applivery como GitHub Secret. Ve a Settings → Secrets and variables → Actions en tu repositorio y crea un nuevo secret llamado `APPLIVERY_TOKEN`.

Usa la integración de Fastlane si tu proyecto ya usa Fastlane para compilar y firmar, ya que el plugin de Applivery simplifica el proceso de subida.

Puedes llamar directamente a la API de subida de Applivery usando `curl` en tu workflow YAML, lo que funciona para cualquier plataforma sin dependencias adicionales.

Configura tu workflow para que se dispare solo con tags de versión (por ejemplo, `v2.4.0`) usando el filtro `tags` en la sección `on` de tu workflow YAML.

Usa dependencias entre jobs definiendo un job `test` y haciendo que el job `deploy` dependa de él con `needs: test`. El job `deploy` solo se ejecutará si el job `test` tiene éxito.

Las más útiles son `${{ github.sha }}` (SHA del commit), `${{ github.ref_name }}` (nombre de rama o tag), `${{ github.run_number }}` (número de ejecución del workflow) y `${{ github.event.head_commit.message }}` (mensaje del commit).

Last updated: June 8, 2026