Quiz : GitHub Actions

b. Sans shell:, le runner exécute bash -e {0}, sans pipefail : le tube renvoie le code de tee. Avec shell: bash, c'est bash --noprofile --norc -eo pipefail {0}. D'où defaults: run: shell: bash dans chaque workflow. Leçon 1.

ubuntu-latest bascule d'Ubuntu 24.04 à 26.04 de façon progressive entre le 19 octobre et le 19 novembre 2026 : deux runs du même commit peuvent tourner sur deux systèmes différents. L'étiquette explicite ne change de version majeure que par un commit, testé et annulable. Les correctifs de sécurité arrivent de toute façon chaque semaine dans les deux images. Leçon 1.

c. GitHub teste le résultat de la fusion de la branche dans sa cible, ce qui révèle les conflits sémantiques. En cas de conflit Git, aucun run pull_request ne démarre. Leçon 2.

Le workflow n'est pas créé, aucun check n'est publié, et la demande de fusion attend indéfiniment un statut qui ne viendra pas. Un job ignoré par une condition if: compte comme réussi, un workflow filtré ne publie rien : on filtre les jobs, pas les workflows exigés. Leçon 2.

github.event.inputs contient des chaînes : on compare 'true' au booléen true. Les types diffèrent, GitHub convertit en nombres : 'true' donne NaN, true donne 1, et NaN n'est égal à rien. Il faut lire inputs.simulation, qui garde le type booléen. Leçon 3.

b. L'expression est remplacée dans le texte du script avant que le shell ne l'interprète : un titre contenant $(commande) est exécuté. En a, le shell lit la valeur comme une donnée. Une condition (c) est évaluée par GitHub, pas par le shell. Leçon 3.

Rien : il n'attend que les services dont l'image ou les options déclarent un contrôle de santé, et l'image officielle postgres n'en déclare pas. Les tests peuvent démarrer pendant l'initialisation de la base, d'où des échecs connection refused aléatoires. Leçon 4.

Avec !cancelled(), un run annulé ignorerait l'agrégateur, et un job ignoré compte comme réussi pour la protection de branche : on pourrait fusionner sans vérification. Avec always(), l'agrégateur s'exécute aussi après une annulation, voit cancelled dans needs.*.result, et échoue. Leçon 4.

Le motif ne correspond à aucun fichier : hashFiles renvoie une chaîne vide, la clé devient constante (pip-), le premier run l'enregistre, et comme une entrée est immuable, le cache n'est plus jamais mis à jour. Leçon 5.

b. C'est le mécanisme des compromissions d'Ultralytics (2024) et de TanStack (2026). cache-mode: none sur le job de publication, et des dépendances verrouillées avec empreintes. Leçon 5.

Émulation (QEMU), construction croisée, runners natifs. Les runners natifs sont rapides et permettent de tester l'image sur son architecture, ce que la construction croisée ne permet pas (exec format error) et que l'émulation ne fait que de façon lente et moins fidèle. Leçon 6.

Une sortie de job n'a qu'une valeur pour l'ensemble de la matrice : on ne peut pas y recueillir une empreinte par architecture. Chaque job de la matrice téléverse un artefact au nom distinct (un fichier vide nommé d'après l'empreinte), que le job d'assemblage récupère. Leçon 6.

Elle est vide : l'env de l'appelant n'est pas transmis au workflow appelé. On passe la valeur en entrée (with:), ou par une variable de configuration (vars). Leçon 7.

./ désigne un chemin de l'espace de travail : il faut un checkout préalable, et c'est ce qui a été récupéré qui est utilisé. $/ (juillet 2026) désigne le même dépôt au commit exact du workflow en cours, sans checkout, ce qui garde un workflow réutilisable cohérent avec ses propres actions quand il est appelé par empreinte. Leçon 7.

Non. Le runner exécute directement le fichier désigné par main, avec son Node 24 embarqué. Toutes les dépendances doivent être dans le dépôt, en pratique empaquetées dans dist/, versionné, et la CI de l'action doit vérifier que dist/ correspond aux sources. Leçon 8.

Dans la variable d'environnement INPUT_FICHIER, que core.getInput("fichier") lit. Les entrées sont toujours des chaînes ; getBooleanInput les convertit selon les valeurs true, True, TRUE, false, False, FALSE. C'est ce qui permet de tester une action localement, comme le runner l'exécute. Leçon 8.

(a) Le job reçoit le secret et l'affiche : le masquage ne reconnaît pas la valeur transformée. (b) Le job qui déclare environment: production échoue avant d'obtenir un runner, car refs/heads/<branche> n'est pas une référence autorisée ; un job qui ne le déclare pas ne reçoit pas le secret. Leçon 9.

c. Les environnements sur dépôt privé demandent au moins Pro ou Team, et les relecteurs requis Enterprise. C'est la situation des dépôts de Lyneko : la compensation se fait chez le fournisseur (identité dédiée, portée minimale, expiration). Leçon 9.

repo:<propriétaire>/<dépôt>:environment:production. L'environnement l'emporte sur la référence ; l'étiquette n'apparaît pas dans le sujet (elle est dans la revendication ref). Leçon 10.

Un nom peut être réutilisé : après le renommage ou la suppression d'une organisation, quelqu'un peut reprendre le nom et obtenir des jetons dont le sujet correspond. Les identifiants numériques ne changent jamais. Le format de sujet immuable (dépôts créés, renommés ou transférés après le 15 juillet 2026) les inclut. Leçon 10.

Un workflow pull_request_target (ou workflow_run), qui s'exécute avec les secrets et un jeton en écriture, récupère et exécute le code d'une demande de fusion venue d'une bifurcation (installation de dépendances, tests, construction). L'auteur de la demande de fusion exécute alors son code avec les privilèges du dépôt. checkout v7 refuse ce schéma par défaut depuis juin 2026. Leçon 11.

Une étiquette est un pointeur que l'on peut déplacer, quel que soit son nom. Les étiquettes v45.0.7, v45.0.8 et v45.0.9 de tj-actions/changed-files désignent aujourd'hui le même commit : elles ont été déplacées par l'attaquant en mars 2025, puis par les mainteneurs. Seule l'empreinte complète d'un commit désigne un contenu immuable. Leçon 11.

N'importe qui peut ouvrir une demande de fusion dont le workflow s'exécutera sur la machine, dans votre réseau. Les approbations des contributeurs externes réduisent le risque sans le supprimer, et un runner persistant laisse en plus au job suivant tout ce que le précédent a laissé. Leçon 12.

Trois minutes : chaque job est facturé à la minute entamée. Regrouper les deux premiers n'économise rien : 69 secondes font deux minutes. Seul un job unique de 78 secondes descendrait à deux minutes, au prix de la séparation des privilèges si l'un des jobs avait des droits d'écriture. Leçon 12.