GitHub Actions — qu’est-ce que c’est, pipelines CI/CD et automatisation

Qu’est-ce que GitHub Actions?

GitHub Actions est une plateforme d’automatisation de flux de travail intégrée à GitHub et lancée en 2019. Elle permet de définir des pipelines CI/CD dans des fichiers YAML stockés directement dans le dépôt. Chaque workflow est déclenché par un événement : push, pull request, création de tag ou selon un calendrier. Contrairement à Jenkins ou TeamCity, aucune infrastructure séparée n’est nécessaire pour héberger un serveur CI.

Dans le contexte du développement mobile, GitHub Actions automatise la compilation APK et IPA, l’exécution de tests unitaires et de tests UI sur des émulateurs, la vérification du code par des linters, la signature et la publication sur Google Play et App Store. La plateforme fournit des minutes gratuites pour les dépôts publics et pour les privés selon le plan tarifaire. Pour les projets mobiles open source, c’est une solution CI/CD complète sans coût.

Architecture de GitHub Actions : Workflows, Jobs et Steps

L’architecture de GitHub Actions se compose de quatre niveaux. Workflow est le fichier YAML racine qui définit l’automatisation. Un Workflow est composé de Jobs, chaque Job s’exécute sur un Runner séparé. À l’intérieur d’un Job, des Steps sont exécutés — commandes séquentielles ou actions externes. Les Events définissent les déclencheurs : push, pull_request, schedule, workflow_dispatch. Un workflow peut également être déclenché manuellement via l’onglet Actions dans l’interface GitHub.

GitHub fournit des runners hébergés avec des OS préinstallés : Ubuntu, macOS et Windows. Pour les compilations iOS, un runner macOS est obligatoire, pour Android — Linux ou macOS. Les self-hosted runners permettent d’exécuter des jobs sur vos propres serveurs avec un environnement personnalisé, ce qui est utile pour les grands projets avec des exigences matérielles spéciales. GitHub prend également en charge les groupes de self-hosted runners pour organiser les files d’attente d’exécution des jobs.

Structure du fichier workflow

Un fichier workflow de base contient les sections : name, on (déclencheurs), jobs. Chaque job spécifie runs-on (type de runner), strategy (matrice), steps (liste d’actions). Les Steps peuvent être des commandes shell ou des actions prêtes du marketplace, connectées via la syntaxe owner/repo@version.

Compilation d’applications mobiles dans GitHub Actions

Pour les compilations Android, un workflow inclut typiquement les étapes : checkout du dépôt, installation du JDK, configuration du cache Gradle, exécution d’assembleRelease. Pour iOS, un runner macOS est requis, installation de Xcode via xcode-select, résolution du provisioning profile et exécution de xcodebuild. La complexité des compilations iOS réside dans le code signing et la gestion des certificats. Les configurations spécifiques à Apple incluent la gestion des provisioning profiles via apple-actions/import-codesign-certs.

La Matrix strategy permet d’exécuter des compilations sur plusieurs versions simultanément. Par exemple : matrice avec versions iOS (15.0, 16.0, 17.0) et Xcode (14, 15). Cela accélère la vérification de compatibilité de l’application avec différentes versions d’OS, bien que cela augmente la consommation de minutes des runners. Pour les projets avec un budget CI limité, la matrice peut être restreinte aux configurations principales uniquement.

Configuration de l’environnement pour Android

GitHub Actions fournit l’action setup-java pour l’installation du JDK et caching pour la mise en cache de Gradle. L’Android SDK est déjà préinstallé sur les runners Ubuntu. Pour les niveaux d’API personnalisés, sdkmanager est utilisé dans une étape séparée. Il est recommandé de créer des workflows séparés pour les compilations Android et iOS, car ils utilisent des runners et des outils de compilation différents.

GitHub Marketplace et actions prêtes

Le GitHub Marketplace contient plus de 15 000 actions créées par la communauté et les développeurs officiels. Pour le développement mobile, les catégories clés incluent : Code signing (apple-actions/import-codesign-certs), tests (react-native-community/action), déploiement (google-github-actions/release-google-play), notifications (slackapi/slack-github-action). Des actions pour Firebase App Distribution, l’upload TestFlight et Fastlane sont également disponibles. Chaque action a une étiquette de compatibilité avec un OS de runner spécifique.

Chaque action a une version, une description, un README et une licence. Lors du choix d’une action, il faut privilégier les actions officielles des fournisseurs (Google, Apple, Microsoft) et vérifiées via Verified Badge. Il est important de spécifier une version majeure fixe (actions/checkout@v4), pas @main, pour éviter des changements inattendus. Si l’action nécessaire n’est pas dans le Marketplace, vous pouvez créer une action personnalisée — localement dans le dépôt (Docker action ou JavaScript action) ou la publier sur le Marketplace.

Actions populaires pour le CI/CD mobile

• actions/checkout — clone le dépôt dans le runner
• actions/setup-java — installe le JDK pour les compilations Android
• gradle/actions/setup-gradle — configure et met en cache Gradle
• apple-actions/import-codesign-certs — importe les certificats pour iOS
• google-github-actions/submit-release — publie sur Google Play Console

Exemple de workflow pour projet iOS

Lors du développement d’applications iOS, il est important de configurer le travail correct avec les simulateurs et les appareils. Le runner macOS-14 fournit un environnement avec Rosetta 2 pour exécuter des compilations Intel sur architecture ARM. Un workflow peut inclure plusieurs schémas de compilation — Debug pour les pull requests et Release pour les tags. GitHub Actions prend en charge l’analyse xcresult via l’action xcparse/sonarqube pour afficher les résultats des tests. Pour envoyer des notifications de statut de compilation, une action Slack ou Telegram peut être ajoutée.

Le code signing pour iOS nécessite l’importation de certificats et de provisioning profiles. Apple-actions fournissent une étape pour importer un certificat P12 et installer un provisioning profile. Les certificats sont stockés comme secrets GitHub Actions et ne sont déchiffrés qu’à l’étape de compilation. Pour l’automatisation de la signature, Fastlane match est utilisé, qui peut être appelé comme une étape séparée dans le workflow.

Considérons un workflow pour une application iOS en Swift qui compile le projet, exécute des tests et crée une compilation archivée. Le workflow utilise le runner macOS-14, Xcode 15.4 et des actions pour la gestion des certificats.

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

Mise en cache des dépendances dans GitHub Actions

La mise en cache réduit le temps de compilation en conservant les dépendances entre les exécutions de workflow. GitHub fournit une mise en cache intégrée via actions/cache. Pour Gradle, ~/.gradle est mis en cache, pour CocoaPods — Pods/, pour SPM — .build/. La clé de cache inclut un hachage du fichier de liste de dépendances — lorsque les dépendances changent, le cache est automatiquement invalidé.

Une attention particulière doit être accordée à la stratégie de restauration du cache (restore-keys). Si la clé exacte n’est pas trouvée, GitHub Actions tente une correspondance partielle via restore-keys. C’est utile lorsqu’une seule dépendance change — le cache reste partiellement utilisable. Pour Gradle, il est supplémentairement recommandé d’activer le Gradle Build Cache, qui met en cache les résultats de compilation entre différents modules du projet.

Exemple de mise en cache Gradle

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

Efficacité du cache pour les projets Android : première compilation sans cache — 8–12 minutes, compilation suivante avec cache — 2–4 minutes. Pour iOS avec CocoaPods, l’économie est similaire. Il est recommandé de combiner actions/cache avec l’action setup-gradle de Gradle pour une gestion optimale du cache. Pour les dépendances npm dans React Native, actions/cache est utilisé avec hachage de package-lock.json. Avec une configuration de cache appropriée, le temps de compilation peut être réduit jusqu’à 70%.

GitHub Actions prend en charge les variables d’environnement au niveau workflow, job et step. Les variables d’environnement peuvent être remplacées : le niveau step a la priorité la plus élevée. Pour les données confidentielles, utilisez toujours des secrets — ils sont chiffrés avec AES-256 et ne sont pas affichés dans les logs. Des règles de protection d’environnement sont également disponibles — approbation manuelle obligatoire avant le déploiement. Pour une sécurité supplémentaire, une approbation obligatoire d’utilisateurs ou d’équipes spécifiques peut être configurée.

GitHub Actions prend également en charge les Reusable Workflows — des pipelines réutilisables qui peuvent être appelés depuis d’autres workflows. Cela permet de créer un workflow de compilation centralisé et de le réutiliser dans tous les dépôts de l’organisation. Un Reusable workflow est appelé par une seule ligne et peut accepter des paramètres d’entrée et des secrets. C’est particulièrement utile pour standardiser les pratiques CI/CD dans les grandes équipes.

Sécurité et bonnes pratiques

Lors de la configuration de GitHub Actions pour des projets mobiles, il est important de suivre les principes de sécurité. OIDC (OpenID Connect) permet d’éliminer les identifiants à longue durée de vie et d’obtenir des jetons temporaires pour les fournisseurs de cloud. N’utilisez jamais de secrets en texte clair dans les scripts — GitHub Actions masque automatiquement les secrets dans les logs.

Pour les projets mobiles, il est essentiel de restreindre l’accès au workflow pour les forks tiers. Utilisez le paramètre pull_request_target avec précaution — il exécute le code de la branche de base, pas du fork. Pour le code signing des applications iOS, il est recommandé de stocker les certificats chiffrés et de les déchiffrer uniquement à l’étape de compilation via gpg ou openssl.