GitHub Actions — cos’è, pipeline CI/CD e automazione

Cos’è GitHub Actions?

GitHub Actions è una piattaforma di automazione dei flussi di lavoro integrata in GitHub e lanciata nel 2019. Consente di definire pipeline CI/CD in file YAML memorizzati direttamente nel repository. Ogni workflow viene attivato da un evento: push, pull request, creazione di tag o secondo una pianificazione. A differenza di Jenkins o TeamCity, non è necessaria un’infrastruttura separata per ospitare un server CI.

Nel contesto dello sviluppo mobile, GitHub Actions automatizza la build di APK e IPA, l’esecuzione di test unitari e test UI su emulatori, la verifica del codice con linter, la firma e la pubblicazione su Google Play e App Store. La piattaforma fornisce minuti gratuiti per repository pubblici e per privati in base al piano tariffario. Per i progetti mobile open source, è una soluzione CI/CD completa senza costi.

Architettura di GitHub Actions: Workflow, Job e Step

L’architettura di GitHub Actions si compone di quattro livelli. Workflow è il file YAML radice che definisce l’automazione. Un Workflow è composto da Job, ogni Job viene eseguito su un Runner separato. All’interno di un Job vengono eseguiti Step — comandi sequenziali o action esterne. Gli Eventi definiscono i trigger: push, pull_request, schedule, workflow_dispatch. Un workflow può anche essere attivato manualmente tramite la scheda Actions nell’interfaccia di GitHub.

GitHub fornisce runner ospitati con OS preinstallati: Ubuntu, macOS e Windows. Per i build iOS è obbligatorio un runner macOS, per Android — Linux o macOS. I self-hosted runner consentono di eseguire job sui propri server con un ambiente personalizzato, utile per progetti grandi con requisiti hardware speciali. GitHub supporta anche gruppi di self-hosted runner per organizzare code di esecuzione dei job.

Struttura del file workflow

Un file workflow di base contiene sezioni: name, on (trigger), jobs. Ogni job specifica runs-on (tipo di runner), strategy (matrice), steps (elenco di azioni). Gli Step possono essere comandi shell o action pronte dal marketplace, collegati tramite la sintassi owner/repo@version.

Build di applicazioni mobili in GitHub Actions

Per i build Android, un workflow include tipicamente i passaggi: checkout del repository, installazione di JDK, configurazione della cache di Gradle, esecuzione di assembleRelease. Per iOS è necessario un runner macOS, installazione di Xcode tramite xcode-select, risoluzione del provisioning profile ed esecuzione di xcodebuild. La complessità dei build iOS risiede nel code signing e nella gestione dei certificati. Le configurazioni specifiche di Apple includono la gestione del provisioning profile tramite apple-actions/import-codesign-certs.

La Matrix strategy consente di eseguire build su più versioni simultaneamente. Ad esempio: matrice con versioni iOS (15.0, 16.0, 17.0) e Xcode (14, 15). Ciò accelera la verifica della compatibilità dell’applicazione con diverse versioni del sistema operativo, sebbene aumenti il consumo di minuti dei runner. Per progetti con budget CI limitato, la matrice può essere limitata alle sole configurazioni principali.

Configurazione dell’ambiente per Android

GitHub Actions fornisce l’action setup-java per l’installazione di JDK e caching per la memorizzazione nella cache di Gradle. L’Android SDK è già preinstallato sui runner Ubuntu. Per livelli API personalizzati, si utilizza sdkmanager in un passaggio separato. Si consiglia di creare workflow separati per i build Android e iOS, poiché utilizzano runner e strumenti di build diversi.

GitHub Marketplace e action pronte

GitHub Marketplace contiene oltre 15.000 action create dalla community e dagli sviluppatori ufficiali. Per lo sviluppo mobile, le categorie chiave includono: Code signing (apple-actions/import-codesign-certs), test (react-native-community/action), deploy (google-github-actions/release-google-play), notifiche (slackapi/slack-github-action). Sono disponibili anche action per Firebase App Distribution, upload TestFlight e Fastlane. Ogni action ha un’etichetta di compatibilità con uno specifico OS del runner.

Ogni action ha una versione, descrizione, README e licenza. Nella scelta di un’action, è opportuno privilegiare quelle ufficiali dei fornitori (Google, Apple, Microsoft) e verificate tramite Verified Badge. È importante specificare una versione maggiore fissa (actions/checkout@v4), non @main, per evitare cambiamenti imprevisti. Se l’action necessaria non è presente nel Marketplace, è possibile creare un’action personalizzata — localmente nel repository (Docker action o JavaScript action) o pubblicarla nel Marketplace.

Action popolari per CI/CD mobile

• actions/checkout — clona il repository nel runner
• actions/setup-java — installa JDK per build Android
• gradle/actions/setup-gradle — configura e memorizza nella cache Gradle
• apple-actions/import-codesign-certs — importa certificati per iOS
• google-github-actions/submit-release — pubblica in Google Play Console

Esempio di workflow per progetto iOS

Nello sviluppo di applicazioni iOS, è importante configurare il corretto funzionamento con simulatori e dispositivi. Il runner macOS-14 fornisce un ambiente con Rosetta 2 per eseguire build Intel su architettura ARM. Un workflow può includere più schemi di build — Debug per le pull request e Release per i tag. GitHub Actions supporta l’analisi di xcresult tramite l’action xcparse/sonarqube per visualizzare i risultati dei test. Per inviare notifiche sullo stato del build, è possibile aggiungere un’action Slack o Telegram.

Il code signing per iOS richiede l’importazione di certificati e provisioning profile. Apple-actions forniscono un passaggio per importare un certificato P12 e installare un provisioning profile. I certificati sono memorizzati come secret di GitHub Actions e vengono decifrati solo nella fase di build. Per l’automazione della firma viene utilizzato Fastlane match, che può essere richiamato come passaggio separato nel workflow.

Consideriamo un workflow per un’app iOS in Swift che compila il progetto, esegue test e crea un build archiviato. Il workflow utilizza runner macOS-14, Xcode 15.4 e action per la gestione dei certificati.

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

Caching delle dipendenze in GitHub Actions

La memorizzazione nella cache riduce i tempi di build preservando le dipendenze tra le esecuzioni del workflow. GitHub fornisce caching integrato tramite actions/cache. Per Gradle viene memorizzato ~/.gradle, per CocoaPods — Pods/, per SPM — .build/. La chiave di cache include un hash del file dell’elenco delle dipendenze — quando le dipendenze cambiano, la cache viene automaticamente invalidata.

Occorre prestare particolare attenzione alla strategia di ripristino della cache (restore-keys). Se la chiave esatta non viene trovata, GitHub Actions tenta una corrispondenza parziale tramite restore-keys. Ciò è utile quando cambia una sola dipendenza — la cache rimane parzialmente utilizzabile. Per Gradle, si raccomanda inoltre di abilitare Gradle Build Cache, che memorizza nella cache i risultati di build tra diversi moduli del progetto.

Esempio di caching di Gradle

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

Efficienza della cache per progetti Android: primo build senza cache — 8–12 minuti, build successivo con cache — 2–4 minuti. Per iOS con CocoaPods, il risparmio è simile. Si consiglia di combinare actions/cache con l’action setup-gradle di Gradle per una gestione ottimale della cache. Per le dipendenze npm in React Native, si utilizza actions/cache con hashing di package-lock.json. Con una configurazione adeguata della cache, il tempo di build può essere ridotto fino al 70%.

GitHub Actions supporta variabili d’ambiente a livello di workflow, job e step. Le variabili d’ambiente possono essere sovrascritte: il livello step ha la priorità più alta. Per i dati riservati, utilizzare sempre i secret — sono crittografati con AES-256 e non vengono visualizzati nei log. Sono disponibili anche regole di protezione dell’ambiente — approvazione manuale obbligatoria prima del deploy. Per una sicurezza aggiuntiva, è possibile configurare l’approvazione obbligatoria da parte di utenti o team specifici.

GitHub Actions supporta anche i Reusable Workflow — pipeline riutilizzabili che possono essere chiamate da altri workflow. Ciò consente di creare un workflow di build centralizzato e riutilizzarlo in tutti i repository dell’organizzazione. Un Reusable workflow viene chiamato con una singola riga e può accettare parametri di input e secret. Ciò è particolarmente utile per standardizzare le pratiche CI/CD in team numerosi.

Sicurezza e buone pratiche

Nella configurazione di GitHub Actions per progetti mobile, è importante seguire i principi di sicurezza. OIDC (OpenID Connect) consente di eliminare le credenziali a lunga durata e ottenere token temporanei per i provider cloud. Non utilizzare mai secret in testo semplice negli script — GitHub Actions maschera automaticamente i secret nei log.

Per i progetti mobile, è fondamentale limitare l’accesso al workflow per i fork di terze parti. Utilizzare l’impostazione pull_request_target con cautela — esegue il codice dal branch base, non dal fork. Per il code signing delle app iOS, si consiglia di memorizzare i certificati crittografati e decifrarli solo nella fase di build tramite gpg o openssl.