Les déclencheurs

Un workflow déclaré sur on: push tourne à chaque poussée, sur chaque branche, y compris quand le commit ne touche que le fichier README.md. Sur une équipe de cinq personnes, cela représente vite plusieurs centaines d'exécutions par semaine dont la plupart ne vérifient rien d'utile. Le problème n'est pas seulement le coût en minutes facturées : c'est la file d'attente. Quand vingt exécutions inutiles occupent les runners, celle qui bloque une fusion urgente attend derrière elles.

Le cas le plus coûteux est plus discret. Vous poussez trois commits d'affilée sur une branche de travail — un correctif, un oubli, une faute de frappe. GitHub lance trois exécutions complètes en parallèle, dont les deux premières testent un état du code que personne ne fusionnera jamais. Elles vont tourner jusqu'au bout, occuper des runners, et leur résultat sera ignoré. Choisir ses déclencheurs et savoir annuler, c'est ce qui sépare une chaîne rapide d'une chaîne qu'on finit par contourner.

push et pull_request : le doublon classique

Ces deux événements se ressemblent mais ne testent pas la même chose. push teste le contenu de la branche telle qu'elle est. pull_request teste, par défaut, une fusion simulée entre la branche source et la branche cible — un commit de fusion éphémère qui n'existe dans aucun dépôt. C'est précisément l'état qui compte avant une fusion, et c'est ce qui permet de détecter un conflit sémantique : deux modifications valides séparément, incompatibles ensemble.