Continuous integration - ApplETS/Notre-Dame GitHub Wiki

🚀 Intégration Continue (CI)

Cette page explique le fonctionnement du CI pour le projet ÉTS Mobile.

🔧 Objectif du CI

Le CI garantit que chaque changement passe par des vérifications automatiques avant d'être intégré :

  • compilation du projet
  • analyse statique
  • tests unitaires / widget
  • génération d'artefacts Android / iOS
  • validation de version et de tags
  • publication pré-release sur GitHub

🧠 Workflows principaux

Le dépôt utilise GitHub Actions avec deux workflows principaux :

  • .github/workflows/dev-workflow.yaml : utilisé pour les pull requests et les validations de développement.
  • .github/workflows/master-workflow.yaml : utilisé pour les push sur master et les déploiements de release.

dev-workflow.yaml

Ce workflow s'exécute sur :

  • pull_request

Il réalise :

  • testing : vérifie le code, exécute les tests
  • coverage : commente la couverture de code sur la PR
  • build : génère les artefacts Android et iOS pour validation

Ce workflow est la première barrière de qualité pour les contributions.

master-workflow.yaml

Ce workflow s'exécute sur :

  • push sur master
  • workflow_dispatch

Il réalise :

  • tag_validation : vérifie la version du pubspec.yaml et la cohérence du tag
  • testing : tests et vérifications
  • coverage : met à jour le badge de couverture de code
  • build : génère des artefacts Android et iOS
  • create_pre_release : crée une pré-release GitHub avec les builds

Ce workflow gère le passage en production/test release du code validé.

🧩 Composants partagés

Plusieurs actions composites sont utilisées pour standardiser l'environnement et les étapes :

  • .github/composite/flutter-setup/action.yaml

    • Installe Flutter
    • Déchiffre et charge les secrets nécessaires
    • Configure l'environnement pour Android et iOS

  • .github/composite/tests/action.yaml

    • Exécute les vérifications principales
    • Lance potentiellement flutter analyze, flutter test, et autres validations

  • .github/composite/ci-build/action.yaml

    • Génère les builds Android et iOS selon la matrice de cible
    • Produit des artefacts téléchargeables pour review

🧪 Jobs CI détaillés

testing

  • Checkout du code
  • Configuration Flutter
  • Exécution des vérifications du projet
  • Résultat attendu : tests réussis et état sain

coverage

  • Récupère l'artefact lcov.info
  • Met à jour le badge de couverture
  • Dans dev-workflow.yaml, commente la couverture sur la PR

build

  • S'exécute sur une matrice de cibles :
    • Android sur ubuntu-latest
    • iOS sur macos-15
  • Les builds sont générées en mode release
  • Les artefacts sont exportés sous forme de apk ou zip
  • fail-fast: false pour obtenir le résultat de toutes les cibles

create_pre_release

  • Télécharge les artefacts de build
  • Crée une pré-release GitHub
  • Utilise gh release create pour générer les notes de release

🔐 Secrets utilisés

Le CI s'appuie sur des secrets GitHub pour déchiffrer les secrets du projet et signer les builds :

  • ENCRYPTED_SIGNETS_API_CERT_PASSWORD
  • ENCRYPTED_GOOGLE_SERVICE_PASSWORD
  • ENCRYPTED_ETSMOBILE_KEYSTORE_PASSWORD
  • ENCRYPTED_KEYSTORE_PROPERTIES_PASSWORD
  • ENCRYPTED_MSAL_CONFIG_PASSWORD
  • MAPS_API_KEY
  • APP_HASH
  • PTA (pour les PRs)
  • GITHUB_TOKEN
  • GIST_COVERAGE_BADGE_TOKEN
  • GIST_ID_COVERAGE_BADGE

Ces secrets ne sont pas contenus dans le dépôt et sont gérés par le compte GitHub du projet.

🌿 Règles de déclenchement

dev-workflow.yaml

  • Exécution sur pull_request
  • Ignore les fichiers :
    • .gitignore
    • .metadata
    • *.md
    • android/fastlane/**
    • ios/fastlane/**
    • .github/**
    • !.github/workflows/dev-workflow.yaml

master-workflow.yaml

  • Exécution sur push vers master
  • Ignore les mêmes fichiers que dev-workflow

Les modifications de documentation pure ou de scripts CI n'entraînent pas de build complet.

🧭 Bonnes pratiques pour les contributeurs

  1. Exécuter localement avant de pousser :

    • flutter pub get
    • flutter analyze
    • flutter test

  2. Respecter les conventions de code et ne pas committer de TODO temporaire.

  3. Vérifier que la PR passe le workflow dev-workflow.

  4. Ne pas merger tant que les tests et le build n'ont pas réussi.

  5. Utiliser les artefacts de build en cas de validation manuelle.

🧰 Commandes utiles pour vérifier localement

flutter clean
flutter pub get
flutter analyze
flutter test
flutter pub run build_runner build --delete-conflicting-outputs

📝 Où trouver les logs

  • GitHub Actions → onglet Actions
  • Workflow concerné : Development workflow ou Master workflow
  • Job concerné : testing, build, coverage, create_pre_release

Cette page a été en partie générée avec l'aide de Claude Haiku 4.5