GitHub Actions — qué es, pipelines CI/CD y automatización

¿Qué es GitHub Actions?

GitHub Actions es una plataforma de automatización de flujos de trabajo integrada en GitHub y lanzada en 2019. Permite definir pipelines CI/CD en archivos YAML almacenados directamente en el repositorio. Cada workflow se activa mediante un evento: push, pull request, creación de tag o según un horario. A diferencia de Jenkins o TeamCity, no se requiere infraestructura separada para alojar un servidor CI.

En el contexto del desarrollo móvil, GitHub Actions automatiza la compilación de APK e IPA, la ejecución de pruebas unitarias y UI en emuladores, la revisión de código con linters, la firma y la publicación en Google Play y App Store. La plataforma proporciona minutos gratuitos para repositorios públicos y para privados según el plan tarifario. Para proyectos móviles de código abierto, es una solución CI/CD completa sin costo.

Arquitectura de GitHub Actions: Workflows, Jobs y Steps

La arquitectura de GitHub Actions consta de cuatro niveles. Workflow es el archivo YAML raíz que define la automatización. Un Workflow se compone de Jobs, cada Job se ejecuta en un Runner separado. Dentro de un Job se ejecutan Steps — comandos secuenciales o actions externas. Los Events definen los desencadenadores: push, pull_request, schedule, workflow_dispatch. Un workflow también puede activarse manualmente a través de la pestaña Actions en la interfaz de GitHub.

GitHub proporciona runners alojados con SO preinstalados: Ubuntu, macOS y Windows. Para compilaciones iOS es obligatorio un runner macOS, para Android — Linux o macOS. Los self-hosted runners permiten ejecutar jobs en tus propios servidores con un entorno personalizado, lo que es útil para proyectos grandes con requisitos especiales de hardware. GitHub también admite grupos de self-hosted runners para organizar colas de ejecución de jobs.

Estructura del archivo workflow

Un archivo workflow básico contiene secciones: name, on (desencadenadores), jobs. Cada job especifica runs-on (tipo de runner), strategy (matriz), steps (lista de acciones). Los Steps pueden ser comandos shell o actions listas del marketplace, conectadas mediante la sintaxis owner/repo@version.

Compilación de aplicaciones móviles en GitHub Actions

Para compilaciones Android, un workflow típicamente incluye pasos: checkout del repositorio, instalación de JDK, configuración de caché de Gradle, ejecución de assembleRelease. Para iOS se requiere un runner macOS, instalación de Xcode mediante xcode-select, resolución del provisioning profile y ejecución de xcodebuild. La complejidad de las compilaciones iOS radica en el code signing y la gestión de certificados. Las configuraciones específicas de Apple incluyen la gestión de provisioning profiles mediante apple-actions/import-codesign-certs.

La Matrix strategy permite ejecutar compilaciones en múltiples versiones simultáneamente. Por ejemplo: matrix con versiones iOS (15.0, 16.0, 17.0) y Xcode (14, 15). Esto acelera la verificación de compatibilidad de la aplicación con diferentes versiones del SO, aunque aumenta el consumo de minutos de runners. Para proyectos con presupuesto CI limitado, la matriz puede restringirse solo a las configuraciones principales.

Configuración del entorno para Android

GitHub Actions proporciona la action setup-java para instalación de JDK y caching para almacenar en caché Gradle. Android SDK ya está preinstalado en los runners Ubuntu. Para niveles de API personalizados, se usa sdkmanager en un paso separado. Se recomienda crear workflows separados para compilaciones Android e iOS, ya que utilizan diferentes runners y herramientas de compilación.

GitHub Marketplace y actions listas

GitHub Marketplace contiene más de 15 000 actions creadas por la comunidad y desarrolladores oficiales. Para el desarrollo móvil, las categorías clave incluyen: Code signing (apple-actions/import-codesign-certs), pruebas (react-native-community/action), despliegue (google-github-actions/release-google-play), notificaciones (slackapi/slack-github-action). También hay actions para Firebase App Distribution, carga en TestFlight y Fastlane. Cada action tiene una etiqueta de compatibilidad con un SO de runner específico.

Cada action tiene una versión, descripción, README y licencia. Al elegir una action, se debe dar preferencia a las oficiales de los proveedores (Google, Apple, Microsoft) y verificadas mediante Verified Badge. Es importante especificar una versión mayor fija (actions/checkout@v4), no @main, para evitar cambios inesperados. Si la action requerida no está en el Marketplace, se puede crear una action personalizada — localmente en el repositorio (Docker action o JavaScript action) o publicarla en el Marketplace.

Actions populares para CI/CD móvil

• actions/checkout — clona el repositorio en el runner
• actions/setup-java — instala JDK para compilaciones Android
• gradle/actions/setup-gradle — configura y almacena en caché Gradle
• apple-actions/import-codesign-certs — importa certificados para iOS
• google-github-actions/submit-release — publica en Google Play Console

Ejemplo de workflow para proyecto iOS

Al desarrollar aplicaciones iOS, es importante configurar el trabajo correcto con simuladores y dispositivos. El runner macOS-14 proporciona un entorno con Rosetta 2 para ejecutar compilaciones Intel en arquitectura ARM. Un workflow puede incluir múltiples esquemas de compilación — Debug para pull requests y Release para tags. GitHub Actions admite el análisis de xcresult mediante la action xcparse/sonarqube para mostrar resultados de pruebas. Para enviar notificaciones de estado de compilación, se puede añadir una action de Slack o Telegram.

El code signing para iOS requiere importar certificados y provisioning profiles. Apple-actions proporcionan un paso para importar un certificado P12 e instalar un provisioning profile. Los certificados se almacenan como secrets de GitHub Actions y se descifran solo en la etapa de compilación. Para la automatización de la firma se utiliza Fastlane match, que puede ser invocado como un paso separado en el workflow.

Consideremos un workflow para una aplicación iOS en Swift que compila el proyecto, ejecuta pruebas y crea una compilación archivada. El workflow utiliza runner macOS-14, Xcode 15.4 y actions para la gestión de certificados.

name: iOS CI

on:
  push:
    branches: ["main"]
  pull_request:
    branches: ["main"]

jobs:
  build:
    runs-on: macos-14
    steps:
      - uses: actions/checkout@v4
      - name: Select Xcode
        run: sudo xcode-select -s /Applications/Xcode_15_4.app
      - name: Install CocoaPods
        run: pod install
      - name: Build and test
        run: xcodebuild clean test -workspace App.xcworkspace
            -scheme App -sdk iphonesimulator
      - name: Archive
        run: xcodebuild archive -workspace App.xcworkspace
            -scheme App -archivePath App.xcarchive

Caché de dependencias en GitHub Actions

El almacenamiento en caché reduce el tiempo de compilación al conservar las dependencias entre ejecuciones de workflow. GitHub proporciona caché integrado mediante actions/cache. Para Gradle se almacena en caché ~/.gradle, para CocoaPods — Pods/, para SPM — .build/. La clave de caché incluye un hash del archivo de lista de dependencias — cuando las dependencias cambian, la caché se invalida automáticamente.

Se debe prestar especial atención a la estrategia de restauración de caché (restore-keys). Si no se encuentra la clave exacta, GitHub Actions intenta una coincidencia parcial mediante restore-keys. Esto es útil cuando solo cambia una dependencia — la caché sigue siendo parcialmente utilizable. Para Gradle, se recomienda adicionalmente habilitar Gradle Build Cache, que almacena en caché los resultados de compilación entre diferentes módulos del proyecto.

Ejemplo de caché de Gradle

- name: Cache Gradle
  uses: actions/cache@v4
  with:
    path: |
      ~/.gradle/caches
      ~/.gradle/wrapper
    key: ${{ runner.os }}-gradle-${{ hashFiles('*.gradle*') }}

Eficiencia de la caché para proyectos Android: primera compilación sin caché — 8–12 minutos, compilación posterior con caché — 2–4 minutos. Para iOS con CocoaPods, el ahorro es similar. Se recomienda combinar actions/cache con la action setup-gradle de Gradle para una gestión óptima de la caché. Para dependencias npm en React Native, se usa actions/cache con hash de package-lock.json. Con una configuración adecuada de caché, se puede reducir el tiempo de compilación hasta en un 70%.

GitHub Actions admite variables de entorno a nivel de workflow, job y step. Las variables de entorno se pueden sobrescribir: el nivel de step tiene la prioridad más alta. Para datos confidenciales, usa siempre secrets — están cifrados con AES-256 y no se muestran en los registros. También están disponibles las reglas de protección de entorno — aprobación manual obligatoria antes del despliegue. Para mayor seguridad, se puede configurar la aprobación obligatoria de usuarios o equipos específicos.

GitHub Actions también admite Reusable Workflows — pipelines reutilizables que se pueden invocar desde otros workflows. Esto permite crear un workflow de compilación centralizado y reutilizarlo en todos los repositorios de la organización. Un reusable workflow se invoca con una sola línea y puede aceptar parámetros de entrada y secrets. Esto es especialmente útil para estandarizar prácticas de CI/CD en equipos grandes.

Seguridad y mejores prácticas

Al configurar GitHub Actions para proyectos móviles, es importante seguir los principios de seguridad. OIDC (OpenID Connect) permite eliminar credenciales de larga duración y obtener tokens temporales para proveedores de nube. Nunca uses secrets en texto plano en scripts — GitHub Actions enmascara automáticamente los secrets en los registros.

Para proyectos móviles, es crítico restringir el acceso al workflow para forks de terceros. Usa la configuración pull_request_target con precaución — ejecuta código de la rama base, no del fork. Para el code signing de aplicaciones iOS, se recomienda almacenar los certificados cifrados y descifrarlos solo en la etapa de compilación mediante gpg u openssl.