GitHub Actions

Salut, c'est Alex de DEV STORIES DOT EU. GitHub Actions, épisode 1 sur 14. La plupart des builds en entreprise sont traités après coup dans un outil totalement séparé. Tu push du code, un context switch se produit, et tu espères qu'un webhook se déclenche correctement sur un serveur distant quelque part ailleurs. Le cas d'usage en entreprise de GitHub Actions comble ce vide en déplaçant l'exécution de ton pipeline juste à côté de ton code source. L'idée reçue classique, c'est de traiter GitHub Actions strictement comme un outil de CI/CD, comme si c'était juste un remplaçant moderne de Jenkins. Appelle-le par son vrai nom. C'est un moteur d'automatisation flexible, event-driven, profondément intégré dans ton repository. Il réagit à pratiquement n'importe quel changement d'état au sein de la plateforme de version control. Prends une configuration d'entreprise standard qui utilise des outils comme GCP Cloud Build ou Azure DevOps. Le code source vit dans GitHub, mais l'exécution se passe ailleurs. Ça demande de gérer des service accounts cross-platform, de maintenir des webhooks fragiles, et de synchroniser les contrôles d'accès entre plusieurs fournisseurs. Quand un pipeline plante, les développeurs quittent leur repository, se connectent à une console cloud séparée, et fouillent dans des logs déconnectés de leur pull request. La proximité avec le code élimine cette friction. Quand ton moteur d'automatisation est construit directement dans la plateforme de version control, tu élimines la taxe d'intégration. L'identité de l'utilisateur, les règles de branch protection, et le contexte du changement de code sont nativement compris par l'instance compute qui fait tourner ton pipeline. Prends un pipeline traditionnel dans un outil de cloud build séparé. En général, il écoute un commit de code, pull les sources, build un artefact, et renvoie un simple statut pass ou fail au repository. Sa vision du monde entière se limite à la compilation de code et au déploiement. Une GitHub Action opère à une échelle beaucoup plus large. Comme elle comprend nativement les events du repository, tu peux build un workflow qui se déclenche au moment exact où une pull request s'ouvre. En un seul run fluide, elle peut lire le payload de l'event, assigner les bons ingénieurs seniors comme reviewers en fonction des fichiers spécifiques qui ont changé, exécuter un linter, et poster les erreurs de syntaxe directement comme des commentaires inline sur les lignes de code exactes. Le développeur résout les problèmes sans jamais quitter la vue de la pull request. Tu automatises le workflow lui-même, pas juste l'artefact de build. D'un point de vue architectural, ça transforme ton repository d'un volume de stockage passif en un contrôleur actif. Tu arrêtes d'automatiser juste tes déploiements et tu commences à automatiser ta gouvernance opérationnelle. Si une issue est taguée avec un label critique, une action peut provisionner automatiquement une base de données de test temporaire. Si une vulnérabilité de sécurité est signalée par un scan de dépendances automatisé, une action peut instantanément ouvrir un ticket de tracking, assigner l'équipe de sécurité, et ping ton système de chat interne. Tout utilise exactement la même infrastructure compute sous-jacente. Dans une grande organisation, tu peux définir ces workflows de manière centralisée et les partager sur des centaines de repositories. Si ton équipe de sécurité met à jour la policy de container scanning requise, elle met à jour une action centrale. Chaque repository qui appelle cette action hérite immédiatement de la nouvelle exigence de sécurité sans que les équipes produit individuelles n'aient à réécrire leurs scripts de pipeline. Cette centralisation offre un effet de levier massif pour les équipes de platform engineering. Voici le point clé. L'architecture d'entreprise lutte constamment contre le tool sprawl. Chaque nouvel outil de pipeline ajoute de la charge cognitive, demande une maintenance dédiée, et crée une nouvelle surface pour les security policies. En consolidant ta couche d'exécution directement dans GitHub, tu standardises le comportement de chaque repository. Exactement la même infrastructure qui déploie tes microservices en production gère aussi la maintenance de ton repository. L'avantage architectural ultime de GitHub Actions, ce n'est pas d'avoir des build agents plus rapides ou un meilleur caching. C'est qu'il supprime la frontière entre le workflow du développeur et le système de continuous integration. Si tu trouves ces épisodes utiles et que tu veux soutenir l'émission, tu peux chercher DevStoriesEU sur Patreon. Merci pour ton écoute, et happy coding à tous !

Salut, ici Alex de DEV STORIES DOT EU. GitHub Actions, épisode 2 sur 14. Un workflow n'est pas juste un simple script qui s'exécute de haut en bas. C'est une machine à états parallélisée qui distribue ton code sur plusieurs machines virtuelles exactement en même temps. Si tu écris ta configuration en t'attendant à un seul processus continu, tes données vont disparaître en plein milieu. Comprendre le modèle mental d'exécution permet d'éviter ça. Au plus haut niveau, on trouve le workflow. C'est un processus automatisé et configurable, défini dans un fichier YAML à l'intérieur de ton repository. Il contient le plan de ce qui doit se passer quand il est déclenché. Un workflow en lui-même n'exécute pas de code directement. Il orchestre le niveau juste en dessous. Un workflow contient un ou plusieurs jobs. C'est là que les limites physiques d'exécution sont définies. Par défaut, chaque job dans un workflow s'exécute en parallèle. Si tu définis un job de build et un job de test, GitHub lance une machine virtuelle séparée, appelée runner, pour chaque job. Ils démarrent exactement en même temps. Ils ne savent rien l'un de l'autre. Le job de build tourne sur le runner A, et le job de test tourne sur le runner B. Comme ils tournent sur des machines virtuelles complètement différentes, ils ne partagent ni système de fichiers, ni variables d'environnement, ni mémoire. À l'intérieur d'un job, le modèle d'exécution change complètement. Un job est composé d'une séquence de steps. Alors que les jobs tournent en parallèle sur différentes machines, les steps s'exécutent séquentiellement sur la même machine. Le step un se termine avant que le step deux ne commence. Puisqu'ils tournent sur le même runner, les steps partagent les données. Dans notre job de build, le step un peut télécharger le code de ton application. Le step deux le compile. Le step trois le package. Comme ces steps se déroulent sur la même machine virtuelle, le step deux lit nativement les fichiers téléchargés par le step un. Ça nous amène à un point de confusion très courant. On confond souvent les steps et les actions. Un step n'est pas une action. Un step est simplement une unité d'exécution à l'intérieur d'un job. C'est un emplacement dans ta séquence. Tu peux remplir cet emplacement de deux manières. Tu peux écrire une commande shell brute, ou tu peux appeler une action. Une action est un bloc de code packagé et réutilisable, conçu pour accomplir une tâche complexe spécifique, comme configurer un environnement de langage. L'action, c'est le payload réutilisable. Le step, c'est le conteneur qui le maintient dans la séquence du job. Reprenons notre scénario de build et de test. Le workflow démarre. Deux runners démarrent simultanément. Sur le runner de build, les steps s'exécutent un par un. Le premier step appelle une action de checkout pour récupérer le repository. Le deuxième step exécute une commande shell pour compiler le code. Ces steps partagent l'espace disque local de manière transparente. Pendant ce temps, sur le runner de test, une séquence de steps complètement différente tourne de manière isolée. Si ton job de test a besoin du résultat compilé du job de build, il ne peut pas juste regarder sur le disque dur. Le job de test est sur un serveur différent. Voici l'idée clé. La limite d'un job est la limite physique de la machine virtuelle, ce qui veut dire qu'écrire un workflow GitHub Actions est en fait un exercice de mapping d'infrastructure. Merci d'avoir passé ce moment avec moi. J'espère que tu as appris quelque chose de nouveau.

Salut, c'est Alex de DEV STORIES DOT EU. GitHub Actions, épisode 3 sur 14. Un simple commit automatisé est pushé sur ton repository. Ce commit déclenche un workflow. Ce workflow fait un autre commit, qui déclenche à nouveau le workflow. En quelques minutes, tu as cramé des centaines de run minutes dans une boucle infinie accidentelle. La façon dont tu évites ça, et dont tu contrôles exactement quand tes workflows s'exécutent, c'est grâce aux triggers et aux filtres basés sur les events. Chaque workflow GitHub Actions commence par le mot-clé on. Ça indique à GitHub quels events doivent réveiller ton workflow. Tu peux spécifier un seul event, comme un push, ou plusieurs events dans un array. Mais les events ne sont pas toujours de simples triggers. Certains events, comme les issues ou les pull requests, ont plusieurs activity types. Quand une issue est ouverte, éditée ou fermée, ça déclenche le même event de base. Si tu écris juste qu'un workflow tourne sur les issues, il va tourner pour toutes ces activités. Pour être précis, tu spécifies les activity types exacts. Tu peux dire à GitHub de ne lancer le workflow que quand une issue est ouverte, en ignorant les éditions ou les fermetures. Ça économise des run minutes et évite des traitements inutiles. Les activity types gèrent ce qui s'est passé, mais les filtres de branch et de path gèrent où ça s'est passé. Quand tu déclenches un workflow sur un push ou une pull request, en général tu ne veux pas qu'il tourne sur absolument toutes les branches. Tu utilises les filtres de branch pour cibler des destinations spécifiques, comme la branch main ou les branches de release. Tu peux aussi filtrer par paths. Si un dev corrige une faute de frappe dans un fichier readme, tu n'as pas besoin de lancer toute ta test suite. Les filtres de path te permettent d'inclure ou d'exclure des fichiers et des répertoires spécifiques. Voici le point clé. Quand tu mélanges des filtres de path positifs et négatifs, l'ordre dans lequel tu les écris a de l'importance. Un filtre positif dit au workflow de tourner si un path spécifique change. Un filtre négatif, indiqué par un point d'exclamation, dit au workflow d'ignorer les changements dans un path. GitHub les évalue de haut en bas. Si tu mets un filtre négatif après un filtre positif, le filtre négatif prend le dessus sur le positif pour tous les fichiers qui correspondent. Mettons ça en pratique. Tu veux déclencher un build à chaque fois que du code est pushé sur la branch main, mais tu veux faire des économies en ignorant les changements qui ne touchent que la documentation. Sous le mot-clé on, tu spécifies l'event push. En dessous, tu définis un filtre de branch pour main. Ensuite, tu ajoutes un filtre de paths. Tu peux commencer par un filtre positif pour tout, en utilisant un wildcard. Juste en dessous, tu ajoutes un filtre négatif pour le dossier docs, en ciblant spécifiquement les fichiers markdown. Si un commit modifie uniquement un fichier markdown dans le dossier docs, le workflow reste en veille. Si un commit modifie un fichier python et un fichier markdown, le workflow tourne parce que le fichier python déclenche le filtre positif. Revenons à cette boucle infinie. Quand ton workflow tourne, GitHub fournit un credential temporaire appelé le GitHub Token pour s'authentifier sur le repository. Par design, tous les events déclenchés avec ce token spécifique ne vont pas créer de nouveaux workflow runs. C'est un mécanisme de sécurité intégré pour éviter les boucles récursives. Cependant, si ton workflow utilise un Personal Access Token pour commiter du code ou pusher des tags, ce filet de sécurité disparaît. Le nouveau commit va déclencher un autre workflow run, qui fait un autre commit, créant une boucle infinie. Si tu dois absolument utiliser un Personal Access Token, tu dois être extrêmement rigoureux avec tes filtres de branch et de path pour t'assurer que le commit automatisé ne remplit pas les conditions de trigger du workflow. La façon la plus efficace d'optimiser tes coûts de compute n'est pas d'écrire du code plus rapide, mais simplement de t'assurer que tes workflows ne tournent que quand c'est absolument nécessaire. Merci d'avoir écouté, happy coding tout le monde !

Salut, c'est Alex de DEV STORIES DOT EU. GitHub Actions, épisode 4 sur 14. Tu essaies d'utiliser une variable d'environnement de runner pour dicter si un job doit démarrer, et ton pipeline échoue avant même de lancer une machine. Tu es certain que la variable existe, mais GitHub agit comme si elle était vide. Le problème ne vient pas de ta variable, c'est ton timing. Pour corriger ça, on doit parler de l'évaluation d'état avec les variables et les contextes. Dans GitHub Actions, l'état de ton workflow est évalué en deux phases complètement séparées, qui se passent à deux endroits complètement différents. C'est la différence fondamentale entre un contexte et une variable d'environnement. Regardons d'abord les contextes. Les contextes sont des collections d'informations évaluées directement par GitHub, avant même que ton workflow ne soit envoyé à un runner. Ils contiennent des données sur le run du workflow, le repository, l'événement webhook qui a déclenché le run, et l'utilisateur qui l'a initié. Comme GitHub évalue les contextes immédiatement, tu peux les utiliser pour contrôler la structure de ton pipeline. Tu accèdes à un contexte en utilisant une syntaxe d'expression spécifique, généralement un signe dollar suivi de doubles accolades contenant le nom du contexte. D'un autre côté, les variables d'environnement par défaut sont évaluées plus tard, directement sur la machine du runner qui exécute ton job. Quand le runner démarre, il configure automatiquement plusieurs variables d'environnement par défaut, comme le nom du repository ou la branche actuelle. Tu y accèdes exactement comme tu le ferais dans un script bash ou PowerShell normal. Tu peux aussi définir tes propres variables d'environnement en utilisant la clé env dans ton fichier de workflow. Tu peux attacher la clé env à un workflow entier, à un seul job, ou à une step spécifique. Voici le point essentiel. Le cycle de vie dicte ce que tu peux utiliser et où. Une erreur courante est d'essayer d'utiliser une variable d'environnement de runner dans une condition if au niveau du job. Si tu dis à un job de s'exécuter uniquement si une variable d'environnement bash spécifique est égale à une certaine valeur, le workflow va échouer. Le runner n'a pas encore démarré. La machine n'existe pas, donc la variable d'environnement n'existe pas. Pour prendre des décisions avant que le runner ne démarre, tu dois utiliser un contexte. Prenons un scénario pratique. Tu veux qu'un job de deploy s'exécute uniquement si le code est mergé dans la branche main. Au niveau du job, tu écris une condition if. Tu utilises l'expression de contexte pour vérifier si le contexte github dot ref est égal à la string refs slash heads slash main. GitHub évalue ça instantanément. Si c'est vrai, GitHub provisionne un runner et lui envoie le job. Une fois que le job est sur le runner et que tes steps commencent à s'exécuter, tu passes aux variables d'environnement. Dans une step de script bash de ce même job, tu pourrais avoir besoin de connaître le nom de la branche pour taguer un build artifact. Là, tu tapes simplement un signe dollar suivi de GITHUB underscore REF. Le runner lit ça depuis l'environnement de son système d'exploitation local. Tu fais référence exactement à la même donnée, le nom de la branche, mais tu y accèdes via des mécanismes complètement différents selon l'endroit où l'exécution se trouve. Les contextes routent le workflow sur les serveurs de GitHub. Les variables d'environnement pilotent les scripts d'exécution sur le runner. Si jamais tu te retrouves à te battre avec des variables vides dans la logique de ton workflow, demande-toi si la machine qui évalue cette logique a réellement déjà démarré. Comme toujours, merci pour ton écoute. On se retrouve dans le prochain épisode.

Salut, c'est Alex de DEV STORIES DOT EU. GitHub Actions, épisode 5 sur 14. Les développeurs génèrent souvent des Personal Access Tokens à longue durée de vie pour des tâches basiques sur leurs repositories, laissant ainsi des credentials permanents traîner dans leur code base. Mais pour la plupart des interactions avec GitHub, tu n'as pas du tout besoin de créer un token : il y a un token sécurisé et éphémère qui t'attend dans chaque job. C'est le sujet de l'épisode d'aujourd'hui : la security boundary, les secrets et le GITHUB_TOKEN. Quand tu déclenches un workflow, GitHub provisionne automatiquement un secret unique appelé GITHUB_TOKEN. Ce n'est pas un Personal Access Token standard. Il fonctionne comme un installation access token de GitHub App à courte durée de vie. Il existe exclusivement pendant la durée du job du workflow. Dès que le job est terminé, ou après un maximum de 24 heures, le token expire et devient complètement inutile. Une erreur courante, c'est de générer un Personal Access Token permanent juste pour qu'un workflow ajoute un label à une issue ou poste un commentaire sur une pull request. Ça élargit inutilement ta surface d'attaque. Le GITHUB_TOKEN natif possède déjà les permissions nécessaires pour interagir avec le repository qui a déclenché le workflow. Si ton job a besoin d'ajouter un label à une issue, tu passes ce token natif à la step qui exécute l'API call. Aucun credential permanent n'est jamais créé, stocké ou exposé. Ça, c'est pour l'interaction avec GitHub en soi. Mais ton workflow aura inévitablement besoin de parler avec le monde extérieur. C'est là qu'interviennent les encrypted secrets personnalisés. Quand tu crées un secret personnalisé, il ne reste pas en plain text sur un serveur GitHub. La valeur est chiffrée localement en utilisant une sealed box Libsodium avant même d'être transmise. Le chiffrement repose sur la cryptographie à clé publique. Quand tu ajoutes un secret via l'interface web ou l'API, GitHub fournit une clé publique. Ton client utilise cette clé pour sceller la box. Seule la machine virtuelle isolée du runner détient la clé privée correspondante nécessaire pour ouvrir cette box, et elle ne déchiffre le payload qu'au moment exact où le job s'exécute. Tu peux définir ces encrypted secrets à différents niveaux selon ton architecture. Les secrets au niveau du repository s'appliquent à une seule code base. Les secrets au niveau de l'organisation te permettent de partager un seul credential, comme un mot de passe de base de données de production, à travers plusieurs repositories. Ça centralise la gestion des credentials, mais ça demande un contrôle strict. Les secrets d'organisation utilisent des access policies où tu définis explicitement quels repositories sont autorisés à lire le secret. Appliquons ça à un scénario concret. Disons que tu as un mot de passe de base de données au niveau de l'organisation qui est requis pour une step de migration de base de données. Tu ne veux pas que ce mot de passe soit accessible à tout le workflow. GitHub Actions impose une security boundary stricte ici. Les secrets ne sont pas automatiquement injectés dans l'environnement de chaque step. Tu dois explicitement mapper le secret à une environment variable dans la step spécifique qui en a besoin. Quand tu écris le fichier du workflow, tu accèdes à la valeur chiffrée en utilisant une référence de context spécifique, en l'appelant depuis le secrets object, et tu l'assignes à une environment variable locale. Parce que tu l'as mappé explicitement, la step avant la migration ne peut pas voir le mot de passe, et la step d'après ne peut pas le voir non plus. Voici l'idée clé. La sécurité dans l'automatisation, c'est minimiser la durée de vie et limiter le scope. Repose-toi sur le GITHUB_TOKEN éphémère pour les actions internes au repository afin d'éviter de gérer des credentials permanents, et mappe strictement les encrypted secrets uniquement aux steps individuelles qui nécessitent un accès externe. C'est tout pour cet épisode. À la prochaine !

Salut, ici Alex de DEV STORIES DOT EU. GitHub Actions, épisode 6 sur 14. Tu configures un workflow multi-job, et pour être sûr que le deuxième job ait tout ce qu'il lui faut, tu regroupes tout ton dossier de dépendances et tu le lui transmets. Mais soudain, ton build prend cinq minutes de plus et ta consommation de stockage explose. Le problème vient d'une confusion fondamentale entre deux mécanismes de données distincts, et c'est exactement ce qu'on va voir dans cet épisode : Optimisation des données : Caching vs Artifacts. On va clarifier les choses tout de suite. Le caching et les artifacts permettent tous les deux de déplacer des fichiers entre tes runners GitHub Actions, mais ils résolvent des problèmes complètement différents. Dis-toi que les artifacts, c'est ce que ton workflow produit. Et le caching, c'est ce que ton workflow consomme. Si tu inverses ces rôles, tu vas créer un goulot d'étranglement silencieux dans tout ton pipeline. Les artifacts sont des fichiers générés que tu veux conserver une fois qu'un job est terminé. Ça peut être un binaire compilé, un rapport de test coverage, ou une archive zippée de ton répertoire de build final. Ils existent pour deux raisons principales. Premièrement, pour te permettre de télécharger le résultat final de ton workflow une fois qu'il est terminé. Deuxièmement, pour faire passer des données générées entre différents jobs au sein du même workflow run. Comme chaque job tourne sur une machine virtuelle toute neuve, tous les fichiers créés dans le job un sont instantanément perdus à la fin de ce job, à moins que tu ne les uploades explicitement. En utilisant l'action upload artifact, tu sauvegardes ces fichiers sur le stockage de GitHub. Ensuite, le job deux utilise l'action download artifact pour les récupérer dans son propre workspace clean. Maintenant, compare ça au caching de dépendances. Le caching est purement une optimisation de performance conçue pour accélérer ton workflow à travers différents runs au fil du temps. Quand tu buildes un logiciel, tu télécharges généralement des milliers de dépendances tierces, comme des packages NPM ou pip. Récupérer tout ça sur le réseau à chaque run, c'est lent. Au lieu de télécharger de nouvelles dépendances à chaque fois, l'action cache sauvegarde ton dossier de dépendances téléchargé sur les serveurs de cache. Elle attribue à ce cache une clé unique, presque toujours basée sur le hash de ton lock file. Lors du workflow run du lendemain, GitHub vérifie si le lock file correspond à une clé existante. Si c'est le cas, il restaure le dossier directement dans ton runner en quelques secondes, en contournant complètement le package registry. Voici le point clé. La plus grosse erreur que tu puisses faire, c'est d'utiliser l'action upload artifact pour déplacer un énorme dossier de dépendances, comme node modules, entre des jobs. Les artifacts traitent les données en les zippant, en les uploadant, en les downloadant et en les dézippant. Faire ça avec des dizaines de milliers de petits fichiers texte ajoute une latence réseau énorme à ton run time et grignote les quotas de stockage de ton compte. Les artifacts ne sont pas conçus pour la vitesse pure ; ils sont conçus pour le transfert sécurisé des données et la conservation permanente des archives. Les caches, en revanche, sont ultra-optimisés pour récupérer rapidement de gros dependency trees, et ils expirent et se suppriment automatiquement pour gagner de la place. Imagine un pipeline bien conçu qui utilise correctement les deux. Tu as un workflow avec un job de build et un job de deploy. Dans le job de build, ta première étape utilise l'action cache pour restaurer instantanément tes dépendances NPM du run d'hier. Ton code compile rapidement, produisant un binaire d'application final. Tu utilises ensuite l'action upload artifact pour sauvegarder uniquement ce fichier binaire. Le job de build se termine, et le runner est détruit. Le job de deploy démarre sur un nouveau runner. Il n'a besoin ni du cache, ni des dépendances NPM. Il utilise juste l'action download artifact pour récupérer le binaire compilé que tu viens de builder, puis il le pousse sur ton serveur de production. Le caching est un raccourci jetable pour les choses que tu télécharges, tandis que les artifacts sont le relais essentiel pour les choses que tu crées. Merci d'avoir écouté. J'espère que tu as appris quelque chose de nouveau.

Salut, ici Alex de DEV STORIES DOT EU. GitHub Actions, épisode 7 sur 14. Un développeur pousse trois commits d'affilée sur une pull request ouverte en cinq minutes. Si ton serveur de CI mouline sur trois suites de tests redondantes, tu crames de l'argent. Tu as besoin d'un moyen de dire au système que seul le code le plus récent compte, et c'est exactement ce que gère le contrôle de flux avec la concurrency. Par défaut, GitHub Actions exécute les workflows déclenchés en parallèle. Si tu pushes cinq fois, ça lance cinq runners indépendants. Pour des checks basiques, ça gaspille des runner minutes. Pour les deploys, c'est carrément dangereux. Si deux runs de workflow essaient de faire un deploy sur le même environnement de staging en même temps, tu crées une race condition. Le commit le plus ancien pourrait même finir son deploy après le plus récent, écrasant tes mises à jour et laissant ton environnement dans un état obsolète. Tu règles ça en utilisant le keyword concurrency. Tu peux l'appliquer au top level de tout le workflow ou le restreindre à un job spécifique. Le mécanisme repose entièrement sur les concurrency groups. Un concurrency group est juste une string que tu définis. Si deux runs partagent exactement le même nom de groupe, GitHub applique des limites de concurrency entre eux. Beaucoup de gens font l'erreur de hardcoder cette string. Si tu définis le nom du groupe avec juste le mot deploy, alors faire un push sur ta branche de testing va annuler un deploy actif sur ta branche main de production. Le nom du groupe doit être dynamique. Tu le construis en utilisant des context variables, comme la référence de la branche actuelle. Si tu nommes le groupe en utilisant le numéro de la pull request, alors les limites de concurrency s'appliquent uniquement aux push dans cette pull request spécifique. Ta branche main reste totalement intacte. Quand un nouveau workflow est déclenché, GitHub vérifie si un run est déjà actif pour ce concurrency group. Si c'est le cas, le comportement par défaut est de placer le nouveau run dans un état pending. Il attend dans une queue. Voici le point essentiel. La queue ne retient qu'un seul job en pending. Si un troisième run est déclenché pendant que le premier est en cours et que le deuxième est en pending, le deuxième run est éjecté de la queue. Seul le tout dernier run a le droit d'attendre. Attendre est plus sûr pour les deploys, mais pour le testing des pull requests, attendre consomme quand même du temps inutilement. C'est là qu'intervient le paramètre cancel-in-progress. C'est un flag booléen que tu ajoutes sous la définition de ton concurrency group. Quand tu mets cancel-in-progress sur true, tu changes le comportement pour passer du queuing au terminating. Revenons au développeur qui pousse trois commits d'affilée. Le premier push déclenche une suite de tests. Deux minutes plus tard, il fait un nouveau push. Comme tu as défini le concurrency group sur le nom de la branche et activé cancel-in-progress, GitHub voit le nouveau run, termine instantanément la suite de tests active pour le premier commit, et commence à tester le deuxième commit. Quand le troisième push arrive une minute plus tard, il termine le deuxième run et lance le troisième. Le développeur obtient toujours le pass ou fail final, mais tu n'as payé l'exécution des tests qu'une seule fois. Les contrôles de concurrency transforment tes pipelines de CI d'un système réactif qui exécute aveuglément chaque trigger, en un système state-aware qui ne dépense des ressources que sur le code qui compte vraiment. Merci de m'avoir écouté, happy coding tout le monde !

Salut, c'est Alex de DEV STORIES DOT EU. GitHub Actions, épisode 8 sur 14. Tes identifiants de base de données de production ne devraient jamais être accessibles à une pull request aléatoire venant d'une feature branch. Pourtant, si tous tes secrets sont stockés au niveau du repository, n'importe quel workflow peut potentiellement les récupérer. C'est exactement pour combler cette faille de sécurité que tu as besoin de contrôler tes déploiements avec les environnements. D'abord, on doit dissiper une idée reçue très courante. Un environnement dans GitHub Actions n'est pas un serveur physique. GitHub ne lance pas de machine virtuelle ou d'instance cloud appelée production pour toi. Un environnement est purement une limite logique configurée dans les paramètres de ton repository GitHub. Il agit comme un gardien, qui contrôle quand un job est autorisé à s'exécuter et quelles données ce job a le droit de voir. La raison principale de cette fonctionnalité, c'est d'appliquer une gouvernance sur les releases et de protéger les données sensibles. Quand tu crées un environnement, tu peux y attacher directement des secrets et des variables spécifiques. Tu pourrais créer un environnement appelé staging et un autre appelé production. Chacun reçoit son propre jeu unique de clés API, stockées exactement sous le même nom de variable. Dans ton fichier de workflow, tu lies un job spécifique à un environnement simplement en indiquant son nom. Quand le workflow s'exécute, le job qui référence l'environnement staging récupère les clés de staging. Le job qui référence l'environnement production récupère les clés de production. Ça isole complètement tes données sensibles. Un job qui tourne dans une feature branch ne peut pas lire les clés de production parce qu'il ne s'exécute pas dans le contexte de l'environnement production. Mais isoler les secrets, ce n'est que la moitié de la puissance des environnements. L'autre moitié, ce sont les règles de protection. Ces règles agissent comme des gates strictes dans ton pipeline de déploiement. La règle de protection la plus courante, c'est d'exiger un reviewer. Voyons comment ça se passe dans un vrai scénario. Tu as un workflow qui build ton application et la déploie automatiquement en staging. Ce job réussit. Le job juste après dans le workflow est configuré pour déployer en production, et il référence ton environnement production. Si tu as configuré une règle exigeant un reviewer pour cet environnement, le workflow s'arrête net. Le job se met en pause. Il n'est pas envoyé à un runner, et les clés API de production restent bien verrouillées et en sécurité. GitHub envoie une notification au manager ou à l'équipe désignée pour indiquer qu'un déploiement est en attente. Le workflow va rester dans cet état en attente jusqu'à ce qu'une action soit prise. C'est seulement quand le manager clique sur approuver dans l'interface GitHub que la gate s'ouvre. À ce moment précis, le job est envoyé à un runner disponible, les secrets de production sont déchiffrés et injectés, et le script de déploiement s'exécute. Tu peux superposer d'autres règles de protection en plus des approbations manuelles. Une option est un wait timer, qui force un job à patienter un nombre de minutes spécifié avant de démarrer. Ça te donne une marge pour annuler un rollout si tu remarques un pic du taux d'erreurs sur tes dashboards de monitoring juste après un déploiement en staging. Tu peux aussi configurer des deployment branches. Ça restreint l'environnement pour qu'il n'accepte que les jobs lancés depuis des branches spécifiques, comme ta branche main ou des release tags spécifiques. Si un développeur essaie de forcer un deployment job en production depuis une bugfix branch aléatoire, la gate de l'environnement rejette tout simplement le run. Voici le point clé. Les environnements découplent tes mécaniques de déploiement de ton contrôle d'accès. Ton fichier de workflow décrit les étapes exactes requises pour déployer ton code, mais les paramètres d'environnement dans GitHub dictent qui a l'autorité pour laisser ça se produire et quels secrets sont déverrouillés à ce moment-là. Si tu aimes ces deep dives techniques, tu peux soutenir l'émission en cherchant DevStoriesEU sur Patreon. Merci pour ton écoute, et happy coding à tous !

Salut, c'est Alex de DEV STORIES DOT EU. GitHub Actions, épisode 9 sur 14. Le credential cloud le plus sécurisé, c'est celui qui expire cinq minutes après la fin de ton deploy. Pourtant, beaucoup d'équipes copient encore des clés administrateur à longue durée de vie dans les settings de leur repository, en espérant qu'elles ne leakent jamais. Aujourd'hui, on règle ça en regardant le Passwordless Cloud Access via OIDC. Historiquement, connecter un workflow GitHub à un cloud provider, ça voulait dire générer une access key dans AWS, Google Cloud ou Azure, et la sauvegarder comme un GitHub Secret à longue durée de vie. Si ce secret leakait, n'importe qui pouvait l'utiliser de n'importe où jusqu'à ce qu'un administrateur le révoque manuellement. On pense souvent qu'OpenID Connect, ou OIDC, c'est juste un nouveau type de secret que tu colles dans ton repository. Ce n'est pas le cas. OIDC remplace complètement les secrets stockés. C'est un protocole qui génère à la volée un token cryptographique dynamique pour prouver l'identité du workflow à ton cloud provider. GitHub agit comme un Identity Provider OIDC. Quand un workflow tourne, il peut demander à GitHub de générer un JSON Web Token, ou JWT. Pour que ça marche, tu dois ajouter une permission spécifique à ton fichier de workflow. Tu configures le bloc permissions pour autoriser l'accès en écriture pour l'ID token. Ça indique à GitHub que le workflow est autorisé à générer un credential d'identité. Voici le point essentiel. Ce token ne donne pas d'accès par lui-même. C'est simplement un document signé numériquement qui contient des claims. Les claims sont des métadonnées qui affirment des faits vérifiables sur le workflow en cours d'exécution. Le token inclut le nom du repository, l'organisation, la branche, l'environnement, et l'event qui a déclenché le run. Comme GitHub signe cryptographiquement le token, ton cloud provider peut faire confiance à ces claims. C'est la base d'un deploy zero-trust. Prenons l'exemple d'un job de deploy qui push une image vers un Elastic Container Registry AWS. Le workflow démarre et demande un token OIDC à GitHub. Le token est généré, avec des claims qui vérifient qu'il vient bien de la branche main de ton repository backend. Le workflow envoie ensuite ce token à AWS. AWS vérifie d'abord la signature numérique pour s'assurer que le token vient bien de GitHub. Ensuite, il lit les claims. Il vérifie ces claims par rapport à une trust policy stricte que tu as définie plus tôt. La policy peut dire qu'elle n'accepte que les tokens de ton repository spécifique, et seulement si le workflow tourne sur la branche main. Comme les claims correspondent, AWS accepte le token. AWS ne renvoie pas de clé permanente. À la place, il émet un access token temporaire. Ce token peut être valide pour seulement quinze minutes. Ton workflow utilise ce credential temporaire pour pusher l'image de container vers la registry. Quand le job se termine, le credential expire. Il n'y a rien à rotate, et rien de stocké dans GitHub qu'un attaquant pourrait extraire. Quand tu mets ça en place, fais très attention au subject claim, souvent appelé le sub claim. C'est le champ principal que les cloud providers utilisent pour filtrer l'accès. Par défaut, GitHub formate le subject claim pour inclure le nom du repository et la référence git, comme la branche ou le tag. Tu dois t'assurer que ta cloud trust policy valide strictement ce subject claim. Si tu vérifies seulement le nom de l'organisation, n'importe quel repository de ton organisation pourrait demander des ressources cloud. En liant l'accès cloud temporaire à des métadonnées de workflow spécifiques, tu garantis qu'un repository compromis ne peut pas toucher à ton infrastructure, à moins que la requête vienne de la branche et de l'environnement exacts auxquels tu fais explicitement confiance. C'est tout pour cet épisode. Merci d'avoir écouté, et continue de coder !

Salut, c'est Alex de DEV STORIES DOT EU. GitHub Actions, épisode 10 sur 14. Quand tu gères la continuous integration sur cinquante repositories, copier-coller exactement le même YAML est un cauchemar de maintenance qui t'attend au tournant. Tu changes un seul outil de scan de sécurité, et d'un coup tu dois mettre à jour manuellement cinquante fichiers différents. Cet épisode parle de scaler des pipelines DRY pour résoudre exactement ce problème. Pour arrêter de te répéter dans GitHub Actions, tu as deux outils principaux. Les Reusable Workflows et les Composite Actions. Les ingénieurs choisissent souvent le mauvais, parce que les deux évitent la duplication. Une Composite Action n'est pas un workflow. C'est simplement un ensemble de steps. Un Reusable Workflow est un pipeline complet qui regroupe des jobs entiers. Si ta logique partagée doit s'étendre sur plusieurs machines, orchestrer des dépendances complexes entre les jobs, ou gérer des secrets de manière sécurisée, tu dois utiliser un Reusable Workflow. Une Composite Action prend une séquence de steps, comme faire un checkout du code, setup un environnement de langage, et installer des dépendances, et les regroupe dans une seule custom action. Quand un workflow utilise cette action, tous ces steps regroupés s'exécutent séquentiellement à l'intérieur du job actuel. La Composite Action ne décide pas sur quel runner elle s'exécute. Elle tourne là où le job parent la place. Elle existe uniquement pour nettoyer la logique de steps répétitifs au sein d'un seul environnement d'exécution. Les Reusable Workflows opèrent à un niveau architectural beaucoup plus élevé. Ce sont des fichiers YAML complets qu'un autre workflow peut trigger. Le workflow qui fait la requête est le caller workflow, et le workflow qui est déclenché est le called workflow. Parce qu'un called workflow définit des jobs entiers, il contrôle l'infrastructure. Un job à l'intérieur du Reusable Workflow pourrait tourner sur un runner Ubuntu pour build une application, pendant qu'un job dépendant tourne sur un runner macOS pour la tester. Prends l'exemple d'une équipe de Platform Engineering qui standardise un pipeline de deploy Node. Ils veulent s'assurer que chaque équipe lance des checks de sécurité identiques avant de shipper du code. Au lieu de faire confiance à cinquante équipes produit pour maintenir des fichiers YAML identiques, les platform engineers créent un Reusable Workflow central dans un repository partagé. Ce fichier central définit la séquence exacte de jobs requis pour scanner, build et deploy l'application. Les cinquante repositories produit créent ensuite un caller workflow minimal. Ce caller workflow contient juste un seul job qui pointe directement vers le fichier partagé de l'équipe plateforme en utilisant son path. Tu passes les données de configuration au called workflow en utilisant des inputs, en spécifiant des paramètres comme le nom de l'environnement cible ou la version de Node. Le caller workflow peut aussi passer des secrets. Tu peux mapper des secrets spécifiques explicitement, ou dire au called workflow d'hériter simplement de tous les secrets disponibles pour le caller. Quand l'équipe plateforme a besoin de rotate un secret de deploy ou d'ajouter un nouvel outil d'analyse statique, elle met à jour le called workflow central. Instantanément, les cinquante repositories lancent le nouveau check de sécurité lors de leur prochain commit. Les équipes produit ne touchent à aucune configuration. Voici l'idée clé. Utilise les Composite Actions pour cacher la logique de steps un peu brouillonne au sein d'un seul environnement, mais utilise les Reusable Workflows pour imposer des architectures de pipeline standardisées dans toute ton organisation. C'est tout pour cet épisode. Merci de ton écoute, et continue de build !

Salut, c'est Alex de DEV STORIES DOT EU. GitHub Actions, épisode 11 sur 14. Un conteneur garantit des versions exactes pour tes outils, mais il s'accompagne d'un coût de latence caché à chaque run de workflow. La cohérence de ton environnement ralentit peut-être ton équipe et l'enferme dans un seul système d'exploitation sans même que tu t'en rendes compte. Créer des custom actions : Docker contre JavaScript résout cette tension. Une custom action, c'est de la logique réutilisable que tu écris une seule fois et que tu partages entre plusieurs repositories. Quand tu en build une, tu dois choisir une architecture d'exécution. Les deux modèles principaux sont JavaScript et Docker. Beaucoup d'ingénieurs choisissent les actions Docker par défaut parce qu'ils veulent une sécurité absolue et des dépendances prévisibles. Ils partent du principe qu'un conteneur est le choix le plus robuste. En réalité, build une action Docker empêche définitivement les runners macOS ou Windows d'utiliser ton outil. Les actions Docker s'exécutent uniquement sur des environnements Linux. Les actions JavaScript adoptent une approche différente. Elles s'exécutent directement sur la machine hôte. Tu écris ta logique, tu la compiles dans un seul fichier avec toutes ses dépendances, et tu fais pointer les métadonnées de l'action vers ce fichier d'entrée. Quand un workflow se déclenche, le runner utilise son runtime Node intégré pour exécuter ton script. Ça découple ta logique du système d'exploitation sous-jacent. Exactement la même action va tourner nativement sur les runners Linux, macOS et Windows sans aucune modification. À l'inverse, les actions Docker packagent le système d'exploitation, les dépendances système et ton code ensemble dans une unité immuable. Tu dictes l'environnement exact. Le runner lit un Dockerfile fourni par ton action, build ou pull l'image du conteneur, et exécute ton code dans cet espace isolé. Voici le point essentiel. L'isolation stricte d'une action Docker introduit une pénalité de cold-start. Prends l'exemple d'une équipe qui build un outil de linting custom pour le partager dans toute son organisation. S'ils le buildent sous forme d'action Docker, le runner doit pull cette image de conteneur avant de pouvoir évaluer la moindre ligne de code. Ça peut ajouter un délai de quinze secondes au démarrage de chaque job de linting. Sur des centaines de pull requests par jour, ce temps d'inactivité s'accumule et se transforme en des heures de compute gaspillées. Si l'équipe build cette même logique de linting en JavaScript, le runner télécharge simplement le fichier de script et l'exécute instantanément. Ton choix d'architecture dicte comment ton action se comporte dans la nature. Si ton outil repose sur des binaires système complexes, qu'il nécessite une version très spécifique d'un compilateur, ou qu'il wrappe de vieux scripts Bash qui sont fragiles en dehors d'une distribution Linux spécifique, Docker est le bon choix. Tu paies la taxe de latence en échange d'une stabilité garantie. Si ton but est de build un outil rapide, largement adopté et qui fonctionne sur n'importe quel type de projet, JavaScript est la meilleure voie. Le choix d'architecture entre Docker et JavaScript pour une custom action n'est jamais une question de langage de programmation dans lequel tu préfères écrire, c'est un vrai trade-off entre un contrôle strict de l'environnement et une vitesse d'exécution cross-platform. C'est tout pour cet épisode. À la prochaine !

Salut, c'est Alex de DEV STORIES DOT EU. GitHub Actions, épisode 12 sur 14. Les runners cloud de GitHub sont super pratiques, jusqu'à ce que tes tests d'intégration aient besoin de taper dans une base de données legacy bien cachée derrière un firewall d'entreprise. D'un coup, un runner public ne peut plus accéder à tes données privées. C'est exactement là qu'intervient la gestion de flotte : Hosted vs Self-Hosted Runners. Par défaut, GitHub Actions utilise des runners GitHub-hosted. Quand un workflow se déclenche, GitHub lance une nouvelle machine virtuelle. Tu peux demander Ubuntu, Windows ou macOS. Le runner exécute ton job, renvoie le résultat, puis la machine virtuelle est immédiatement détruite. C'est un environnement tout neuf à chaque fois. Tu ne gères pas l'OS, tu n'installes pas de patchs de sécurité, et tu n'as pas à t'inquiéter des fichiers restants d'un build précédent. Mais cette isolation est une arme à double tranchant. Comme ces runners tournent dans l'infrastructure cloud de GitHub, ils fonctionnent avec des adresses IP dynamiques et n'ont aucun accès direct à tes réseaux privés. Si tu as une application interne, ou une base de données qui ne peut pas être exposée sur l'internet public, tu as besoin d'un runner qui vit à l'intérieur de ton propre périmètre de sécurité. C'est ce qu'on appelle un self-hosted runner. C'est toi qui fournis le hardware. Ça peut être un serveur physique dans un data center, une machine virtuelle chez ton cloud provider, ou un container. Tu installes l'application GitHub Actions runner sur cette machine. Le runner se connecte vers l'extérieur à GitHub, récupère les jobs en attente, les exécute en local, et renvoie les logs. Comme il est sur ton réseau, il peut communiquer de façon sécurisée avec ton infrastructure interne sans avoir à percer des trous dans ton firewall. Voici le point clé. Tu possèdes le hardware, ce qui veut dire que tu gères la maintenance. Tu es responsable des mises à jour de l'OS, de la sécurité du réseau, et de l'installation des dépendances nécessaires comme les runtimes de langage ou les outils de build. Une erreur courante est de penser que les self-hosted runners se comportent exactement comme les runners hosted. Ce n'est pas le cas. Les runners GitHub-hosted sont éphémères par design. Les self-hosted runners standards sont stateful. Quand un job se termine sur un self-hosted runner par défaut, la machine continue de tourner. Si ton job écrit un fichier temporaire, lance un process en background, ou pull une grosse image de container, tout ça reste sur le disque quand le job suivant démarre. Ça crée de sérieux risques de contamination croisée. Un script de build défectueux dans une pull request pourrait laisser des fichiers corrompus derrière lui, et faire planter le job de deploy qui tourne juste après. Tu dois configurer activement ton infrastructure self-hosted pour qu'elle soit éphémère si c'est ce que tu veux, souvent en utilisant des webhooks pour lancer des containers tout neufs pour chaque job. Si tu as simplement besoin de plus de puissance de calcul ou d'une adresse IP statique, mais que tu veux quand même que GitHub gère la maintenance de la machine, il y a un juste milieu qu'on appelle les larger runners. Ce sont des machines GitHub-hosted où tu définis les specs hardware et les features réseau, mais elles restent éphémères et gérées par GitHub. Au final, le choix entre hosted et self-hosted se résume rarement à une simple question de coûts de compute. C'est un trade-off fondamental entre le côté pratique d'un environnement jetable et zéro maintenance, et la nécessité de contrôler tes propres frontières réseau. Merci d'avoir passé quelques minutes avec moi. À la prochaine, et porte-toi bien.

Salut, ici Alex de DEV STORIES DOT EU. GitHub Actions, épisode 13 sur 14. Tu as une équipe immense et, à 9 heures du matin, une centaine de développeurs pushent du code en même temps. Tes serveurs de build statiques saturent sous la file d'attente, ou alors tu les as surdimensionnés et ils restent là à gaspiller du compute qui coûte cher toute la nuit. Kubernetes Scale: Actions Runner Controller résout ce problème en transformant ton pipeline de build en un système dynamique et container-native. Les self-hosted runners classiques sont généralement des machines virtuelles statiques ou des conteneurs long-lived. Tu les configures, tu les enregistres sur un repo, et ils restent là à faire du polling pour récupérer du travail. Cette configuration te garantit de payer pour du temps d'inactivité, et quand un pic soudain de builds survient, ta file d'attente s'allonge simplement jusqu'à ce qu'un runner existant termine son job en cours. Actions Runner Controller, ou ARC, change fondamentalement ce modèle. ARC est un opérateur Kubernetes qui orchestre des runner scale sets en auto-scaling. Au lieu de maintenir des worker nodes permanents, il provisionne des runners éphémères en Just-in-Time, en fonction de la taille exacte de ta file d'attente. Pour réussir ça sans exploser les API rate limits, ARC s'appuie sur deux composants architecturaux principaux au sein de ton cluster Kubernetes. Le premier est le pod Listener. Le Listener utilise un long poll HTTPS pour se connecter à GitHub. Plutôt que de t'obliger à ouvrir des ports inbound sur le firewall pour recevoir des webhooks, le Listener contacte GitHub et garde la connexion ouverte. Il reste là tranquillement à attendre que GitHub lui fasse redescendre un message Job Available. Quand le Listener reçoit ce message, il transmet l'information au pod Controller. Le Controller agit comme le moteur de provisioning. Il parle immédiatement à l'API Kubernetes pour démarrer un tout nouveau pod runner spécifiquement pour ce job en attente. Ce pod est un runner éphémère Just-in-Time. Il boote, reçoit un registration token à courte durée de vie, exécute le workflow, puis se termine immédiatement. Repensons à ce rush de code de 9 heures du matin. Une centaine de développeurs pushent des commits exactement en même temps. Le pod Listener détecte l'afflux soudain de messages Job Available en provenance de GitHub. Il alerte le Controller, qui demande instantanément une centaine de pods Kubernetes éphémères. Ton cluster scale out, en allouant des nodes si nécessaire, et les jobs s'exécutent en parallèle. À mesure que chaque workflow se termine, son pod est complètement détruit. À 9 heures 15, la file d'attente est vide, et ton nombre de runners scale pour retomber à zéro. Tu as utilisé du compute massivement parallèle pendant exactement quinze minutes, et ensuite tu as arrêté de payer pour ça. Voici le point clé. Parce que chaque job tourne dans un pod isolé, fraîchement provisionné et détruit juste après l'exécution, tu élimines complètement la contamination de state entre les builds. Un cache dirty, un background process qui traîne, ou une variable d'environnement modifiée par un run précédent ne peuvent tout simplement pas casser le suivant. Tu gagnes la sécurité d'un environnement de build immaculé à chaque fois, couplée à l'efficacité de compute exacte de l'auto-scaling Kubernetes. La vraie valeur de l'Actions Runner Controller, c'est qu'il t'évite de traiter les runners d'intégration continue comme une infrastructure lourde que tu dois maintenir, pour les transformer en compute purement éphémère qui n'existe que pendant qu'un job est en train de tourner. Merci d'avoir passé quelques minutes avec moi. À la prochaine, et à plus.

Salut, c'est Alex de DEV STORIES DOT EU. GitHub Actions, épisode 14 sur 14. Un utilisateur télécharge ton outil en ligne de commande compilé depuis une page de release. Si une dépendance compromise ou un acteur malveillant a remplacé ce binaire après son build, une simple vérification de checksum ne le sauvera pas. Les hashs standards prouvent uniquement que le fichier téléchargé correspond au fichier hébergé, et non d'où il vient réellement. Pour garantir qu'un fichier a été généré par ton code exact, tu as besoin de la Supply Chain Integrity avec des Attestations. Une attestation n'est pas juste un log de build ou un fichier texte contenant un hash posé à côté de ta release. C'est une déclaration signée cryptographiquement et infalsifiable sur la provenance d'un artifact. Elle lie directement ton binaire final au commit SHA exact, au workflow run spécifique, et à l'identité OpenID Connect de l'environnement de build. Le processus se déroule entièrement dans ton workflow GitHub Actions. Après la compilation de ton code, tu utilises l'action officielle de build provenance. Cette action calcule le checksum de ton artifact final et contacte une autorité de signature centralisée, plus précisément Sigstore. Le workflow échange son token OpenID Connect temporaire, spécifique au job, contre un certificat de signature à courte durée de vie. Parce que ce token est généré par GitHub Actions et mappé directement à ton repository, il sert de carte d'identité infalsifiable pour le workflow runner. Cette interaction génère un enregistrement cryptographique permanent. Cet enregistrement affirme sans équivoque que ce hash de fichier exact a été produit par ton repository, déclenché par un commit spécifique, pendant un workflow run spécifique. La signature est attachée à l'artifact, créant un ensemble de preuves qui voyage avec le fichier, peu importe où il est hébergé. Voici le point clé. La vraie valeur de sécurité se trouve côté utilisateur. Quand un utilisateur télécharge ton outil en ligne de commande, il n'a pas à faire aveuglément confiance au fournisseur d'hébergement ou au miroir de téléchargement. Avant d'exécuter le binaire, il utilise la GitHub CLI pour vérifier l'attestation localement. Il lance une commande attestation verify sur l'exécutable téléchargé, en spécifiant explicitement le propriétaire de ton repository comme source attendue. La CLI inspecte la signature cryptographique et la vérifie par rapport au transparency log public. Si la signature est valide, ça prouve mathématiquement que le fichier a été compilé par ton workflow officiel. Si un acteur malveillant a intercepté le téléchargement, altéré la compilation, ou remplacé le binaire sur la page de release, la vérification échoue instantanément. La signature ne peut pas être falsifiée car l'attaquant ne pourra jamais posséder le token d'identité OpenID Connect temporaire généré à l'intérieur de ton workflow run sécurisé. L'identité est inextricablement liée à l'infrastructure GitHub Actions au moment exact du build. Ce mécanisme comble une faille critique dans la sécurité de la software supply chain. Tu ne demandes plus aux utilisateurs de faire confiance à un emplacement de stockage. À la place, l'artifact devient auto-authentifiant. Les attestations font passer ton modèle de sécurité de la confiance en l'endroit où vit un fichier, à la preuve mathématique de l'endroit où il est né. Puisque c'est le dernier épisode de notre série sur GitHub Actions, je t'encourage vivement à passer à la pratique et à commencer à créer ces workflows toi-même. Rends-toi sur devstories dot eu pour suggérer des sujets que tu aimerais voir abordés dans nos futures séries. C'est tout pour cet épisode. Merci pour ton écoute, et continue à développer !