
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
curlen 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,.aabu otro formato compatible).
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.
Abre tu repositorio de GitHub.
Ve a Settings → Secrets and variables → Actions.
Haz clic en New repository secret.
Establece el nombre como
APPLIVERY_TOKEN.Pega tu App API Token de Applivery como valor.
Haz clic en Add secret.
Una vez guardado, referéncialo en tu workflow YAML como ${{ secrets.APPLIVERY_TOKEN }}.
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.
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
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.