# GitHub Actions

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

Source: https://docs.applivery.com/es/app-distribution/ci-cd/github-actions/  •  Last updated: 2026-06-08

**Answers:** ¿Cómo integro Applivery con GitHub Actions? · ¿Cómo guardo mi token de Applivery de forma segura en GitHub Actions? · ¿Cómo disparo la subida a Applivery solo en Builds de release? · ¿Qué variables de contexto de GitHub Actions puedo usar con Applivery?

---

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

![github](https://docs.applivery.com/int/_r2/media/09ac0a4e-3ad8-478f-9f15-3474973eec71/66677e61-987d-457e-aaa9-3e410e59b73f.png)

[GitHub Actions](https://github.com/features/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](https://docs.applivery.com/en/app-distribution/api/app-api-token/).

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

* * *

**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 }}`.

:::info
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.
:::

**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](https://docs.applivery.com/en/app-distribution/ci-cd/fastlane/).

### Workflow YAML

```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

```ruby
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
```

**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

```yaml
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

```yaml
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:

```yaml
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:

```yaml
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](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/accessing-contextual-information-about-workflow-runs).

* * *

## 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](https://docs.applivery.com/en/app-distribution/api/builds/upload-build/).