Cas pratiques GitHub Actions

Contexte : L'équipe souhaite ajouter une vérification de qualité de code via un script npm run lint. Le Problème : Le workflow actuel exécute uniquement les tests et ignore les règles de lint. Contraintes : Ajouter une étape lint avant l'exécution des tests. Le job doit échouer si le lint échoue. Livrable attendu : Modifier le workflow YAML pour intégrer correctement une étape de lint dans la séquence CI.

Contexte : Un script de test nécessite une variable d'environnement APP_ENV définie à test. Le Problème : Le workflow ne définit pas cette variable, causant des erreurs lors de l'exécution. Contraintes : Ajouter la variable d'environnement dans le job sans modifier le code source. Livrable attendu : Modifier le workflow YAML pour injecter correctement la variable d'environnement dans le job.

Contexte : Une application nécessite Node 18 pour fonctionner correctement. Le Problème : Le workflow GitHub Actions utilise Node 16, provoquant des erreurs lors de l'exécution des tests. Contraintes : Modifier uniquement la version Node utilisée dans le workflow. Aucun changement du code applicatif. Extrait actuel : - uses: actions/setup-node@v3 with: node-version: 16 Livrable attendu : Adapter le workflow pour utiliser la version correcte de Node.

Contexte : Votre équipe a mis en place un workflow GitHub Actions pour exécuter des tests automatiquement à chaque push sur la branche main. Le Problème : Malgré plusieurs commits récents, aucun workflow ne se déclenche. Après inspection, le fichier YAML semble mal configuré. Contraintes : Vous devez corriger uniquement le fichier YAML. Le workflow doit se déclencher sur chaque push vers main. Aucun changement dans le code applicatif. Workflow actuel : name: CI on: push: branches: - master jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 Livrable attendu : Corriger le workflow pour qu'il se déclenche correctement sur la branche main.

Contexte : Le pipeline utilise une version ancienne d'une action officielle. Le Problème : GitHub affiche un avertissement indiquant que la version utilisée est obsolète. Contraintes : Mettre à jour vers une version stable récente sans modifier la logique du workflow. Extrait actuel : - uses: actions/checkout@v2 Livrable attendu : Adapter le workflow pour utiliser une version plus récente et stable de l'action concernée.

Contexte : L'équipe souhaite automatiser la construction d'une image Docker à chaque push sur main. Le Problème : Aucun workflow n'est configuré pour builder l'image. Contraintes : Utiliser docker build dans GitHub Actions sans push vers un registry externe. Livrable attendu : Fournir un workflow YAML simple permettant de construire l'image Docker lors d'un push sur main.

Contexte : Un projet Node.js doit exécuter automatiquement ses tests à chaque Pull Request. Le Problème : Aucun pipeline CI n'est actuellement configuré. Contraintes : Utiliser GitHub Actions. Installer Node 18 et exécuter npm install puis npm test. Le workflow doit se déclencher sur pull_request. Livrable attendu : Fournir un fichier YAML complet permettant d'exécuter les tests automatiquement lors de l'ouverture ou mise à jour d'une Pull Request.

Contexte : Une équipe souhaite pouvoir déclencher un workflow manuellement depuis l'interface GitHub. Le Problème : Le workflow actuel ne se déclenche que sur push. Contraintes : Ajouter la possibilité de déclenchement manuel sans supprimer le déclenchement automatique existant. Livrable attendu : Modifier le fichier YAML pour inclure workflow_dispatch tout en conservant les autres événements déjà configurés.

Contexte : Un monorepo contient plusieurs projets, mais le workflow ne doit s'exécuter que lorsque le dossier backend/ est modifié. Le Problème : Actuellement, le pipeline se déclenche sur chaque modification, même non pertinente. Contraintes : Utiliser la configuration paths dans l'événement push. Livrable attendu : Adapter le workflow pour qu'il ne s'exécute que lorsque des fichiers du dossier backend/ sont modifiés.

Contexte : Le pipeline CI est lent car npm install est exécuté à chaque run. Le Problème : Aucune stratégie de cache n'est configurée. Contraintes : Utiliser les mécanismes natifs GitHub Actions pour mettre en cache les dépendances Node.js. Livrable attendu : Adapter le workflow pour intégrer un cache efficace basé sur package-lock.json afin d'accélérer les exécutions futures.

Contexte : Une application doit être déployée en production uniquement après validation manuelle. Le Problème : Le workflow actuel déploie automatiquement sans validation. Contraintes : Utiliser les environnements GitHub avec protection et approbation manuelle. Livrable attendu : Adapter le workflow pour cibler un environment protégé nécessitant une validation avant exécution du job de déploiement.

Contexte : Plusieurs repositories utilisent le même pipeline de test et souhaitent éviter la duplication de configuration. Le Problème : Chaque projet possède son propre workflow copié-collé, rendant la maintenance difficile. Contraintes : Créer un workflow réutilisable déclenché via workflow_call et configurable via inputs. Livrable attendu : Proposer un exemple de workflow réutilisable et expliquer comment l'appeler depuis un autre repository.

Contexte : Une application doit être déployée automatiquement uniquement lorsque des commits sont poussés sur la branche main. Le Problème : Le workflow actuel déclenche le déploiement sur toutes les branches. Contraintes : Les tests doivent continuer à s'exécuter sur toutes les branches, mais l'étape de déploiement doit être conditionnelle. Livrable attendu : Adapter le workflow pour ajouter une condition if basée sur github.ref afin de restreindre le déploiement à main uniquement.

Contexte : L'équipe souhaite déclencher une étape spécifique uniquement si le message de commit contient le mot release. Le Problème : Actuellement, toutes les étapes s'exécutent systématiquement. Contraintes : Utiliser une condition if basée sur github.event.head_commit.message. Livrable attendu : Fournir un workflow intégrant une étape conditionnelle exécutée uniquement si le message de commit contient un mot-clé précis.

Contexte : Le pipeline installe des dépendances Python via pip et reste lent malgré un cache existant. Le Problème : Le cache n'est pas correctement invalidé lorsque requirements.txt change. Contraintes : Mettre en place une clé de cache dynamique basée sur le hash du fichier requirements.txt. Livrable attendu : Adapter le workflow pour utiliser une clé de cache appropriée garantissant un cache efficace et correctement invalidé.

Contexte : Un projet open source doit être compatible avec plusieurs versions de Node.js. Le Problème : Le workflow teste uniquement Node 18, laissant un risque d'incompatibilité avec d'autres versions supportées. Contraintes : Utiliser une stratégie matrix pour tester au minimum Node 16, 18 et 20. Les tests doivent s'exécuter en parallèle. Livrable attendu : Proposer un workflow utilisant strategy.matrix afin d'exécuter automatiquement les tests sur plusieurs versions de Node.

Contexte : Une application Node.js doit exécuter des tests puis construire une image Docker uniquement si les tests passent. Le Problème : Le workflow actuel exécute toutes les étapes dans un seul job, rendant la lecture difficile et empêchant un contrôle clair des dépendances. Contraintes : Séparer le workflow en deux jobs distincts : test et build. Le job build ne doit s'exécuter que si test réussit. Aucun outil externe. Livrable attendu : Fournir un workflow GitHub Actions structuré avec plusieurs jobs et la directive needs garantissant une exécution conditionnelle propre.

Contexte : Une équipe souhaite exécuter automatiquement des tests de régression chaque nuit. Le Problème : Aucun déclenchement programmé n'est configuré. Contraintes : Ajouter un événement schedule avec une expression cron valide. Conserver les autres déclencheurs existants. Livrable attendu : Adapter le workflow pour inclure une exécution planifiée quotidienne via cron tout en maintenant les déclencheurs actuels.

Contexte : Une application est buildée dans un job, puis testée dans un second job. Le Problème : Les fichiers générés lors du build ne sont pas accessibles dans le job suivant. Contraintes : Utiliser actions/upload-artifact et actions/download-artifact pour transférer les fichiers entre jobs. Livrable attendu : Fournir un workflow multi-jobs utilisant correctement les artefacts pour partager les fichiers générés.

Contexte : Une application doit se connecter à un registry Docker privé pour pousser une image. Le Problème : Les identifiants sont actuellement écrits en clair dans le workflow YAML. Contraintes : Utiliser les secrets GitHub (Settings > Secrets) et les injecter correctement dans le job. Aucun stockage en clair autorisé. Livrable attendu : Fournir un exemple de workflow utilisant correctement les secrets pour authentification Docker sans exposer d'informations sensibles.

Contexte : Une application doit être déployée successivement en staging puis en production via GitHub Actions, avec validation humaine entre les deux environnements. Le Problème : Le workflow actuel déploie directement en production après les tests, sans séparation claire des environnements ni promotion contrôlée. Contraintes : Utiliser plusieurs jobs avec environnements GitHub protégés. Le déploiement production doit dépendre du succès du staging et nécessiter une approbation manuelle. Livrable attendu : Proposer un workflow structuré avec gestion d'environnements, dépendances entre jobs et promotion contrôlée vers la production.

Contexte : Un repository principal doit déclencher un workflow dans un repository secondaire après validation. Le Problème : Les workflows actuels sont isolés et ne communiquent pas entre repositories. Contraintes : Utiliser repository_dispatch ou workflow_dispatch via API GitHub sécurisée. Livrable attendu : Décrire une solution permettant à un workflow de déclencher un pipeline dans un autre repository de manière sécurisée.

Contexte : Un monorepo contient plusieurs applications indépendantes (frontend, backend, infra). Le Problème : Chaque push déclenche l'intégralité des pipelines, même si un seul dossier est modifié, générant un gaspillage de ressources CI. Contraintes : Mettre en place une logique conditionnelle avancée basée sur paths et éventuellement des jobs dynamiques. Livrable attendu : Proposer un workflow optimisé capable de détecter les changements par dossier et d'exécuter uniquement les pipelines nécessaires.

Contexte : Un audit sécurité révèle que le workflow GitHub Actions dispose de permissions excessives par défaut. Le Problème : Les tokens générés automatiquement ont des droits trop larges sur le repository. Contraintes : Appliquer le principe du moindre privilège via la clé permissions dans le workflow. Livrable attendu : Proposer une configuration réduisant les permissions globales et attribuant uniquement les scopes nécessaires à chaque job.

Contexte : Un repository contient des manifestes Kubernetes versionnés. Le Problème : Les changements d'infrastructure ne déclenchent aucun processus automatisé de validation ou d'application. Contraintes : Mettre en place un workflow qui valide les manifestes (lint, dry-run) puis applique les changements uniquement sur branche main. Livrable attendu : Décrire un pipeline GitHub Actions structuré pour un workflow GitOps avec validation préalable et déploiement contrôlé.

Contexte : Une application doit être buildée pour plusieurs systèmes (linux, windows, macos). Le Problème : Le workflow actuel ne supporte qu'une seule plateforme et ne combine pas correctement les artefacts produits. Contraintes : Utiliser une matrix multi-os et agréger les artefacts dans un job final. Livrable attendu : Proposer un workflow utilisant strategy.matrix sur plusieurs runners et centralisant les artefacts pour une release unifiée.

Contexte : Un pipeline comporte plusieurs jobs interdépendants avec des chemins d'exécution différents selon les résultats intermédiaires. Le Problème : La logique actuelle est linéaire et ne permet pas de gérer des scénarios conditionnels complexes. Contraintes : Utiliser needs, if conditionnels avancés et outputs de jobs pour orchestrer un flux d'exécution dynamique. Livrable attendu : Décrire un workflow structuré capable d'orchestrer des jobs dépendants avec gestion conditionnelle avancée et partage de données entre jobs.

Contexte : Un projet complexe combine Node, Docker et Terraform. Le Problème : Les temps d'exécution CI sont élevés car chaque étape reconstruit ses dépendances. Contraintes : Mettre en place des stratégies de cache distinctes pour npm, Docker layers et Terraform providers. Livrable attendu : Proposer une architecture de workflow optimisée utilisant plusieurs niveaux de cache cohérents et correctement invalidés.

Contexte : Une application doit être déployée sur un cloud provider sans stocker de clés longues durées dans les secrets GitHub. Le Problème : Le workflow actuel utilise des credentials statiques exposés dans les secrets du repository. Contraintes : Mettre en place une authentification basée sur OIDC avec GitHub Actions. Aucun secret cloud statique autorisé. Livrable attendu : Décrire une configuration workflow utilisant l'authentification OIDC native de GitHub pour accéder au provider cloud de manière sécurisée et éphémère.

Contexte : Une application déployée automatiquement peut rencontrer des erreurs après mise en production. Le Problème : Le workflow ne prévoit aucune stratégie de rollback automatique en cas d'échec des tests post-déploiement. Contraintes : Implémenter une logique conditionnelle permettant de déclencher un rollback si une étape de vérification échoue. Livrable attendu : Décrire une architecture GitHub Actions intégrant un job de validation post-déploiement et un job de rollback conditionnel.