Résumé

  • La concurrence GitHub Actions contrôle les jobs ou runs qui résolvent vers un même groupe ; l’attente, le remplacement et l’annulation suivent une politique propre au groupe.
  • GitHub précise qu’une valeur de concurrence et un environnement ne sont pas automatiquement liés.
  • Une conclusion sur la sérialisation exige la clé effective, les membres et leurs dispositions, l’exécution et une observation séparée de la cible.

Dire qu’une production est « sérialisée » peut décrire une intention de planification plutôt qu’un fait sur la cible. GitHub Actions permet de déclarer un groupe de concurrence pour un workflow ou un job. Cela peut empêcher l’exécution parallèle du travail qui partage ce groupe, remplacer un run en attente ou, si une file est explicitement choisie, conserver davantage de travail en attente. Le contrôle est utile, mais sa portée commence et s’arrête aux jobs ou runs qui résolvent réellement vers la même clé.

La documentation distingue plusieurs dispositions. Avec le comportement ordinaire, un travail peut être en cours et un autre en attente ; l’arrivée d’un candidat supplémentaire peut remplacer celui qui attendait déjà. queue: max permet une file bornée. cancel-in-progress: true peut également arrêter un travail déjà en cours. Ces états ne racontent pas la même histoire. Une attente ne prouve pas qu’une attente antérieure subsiste. Une annulation ne dit pas quelles étapes avaient achevé un appel externe, une publication d’artefact ou une modification cible avant l’arrêt.

L’ordre est tout aussi borné. GitHub décrit le traitement FIFO selon le moment où le run commence à attendre, non selon l’instant de déclenchement, et avertit que le moment réel de départ varie. Une clé de groupe ne devient donc pas un récit chronologique universel. Une affirmation d’ordre demande la clé développée, les identités de run et de job, leurs moments d’attente, de départ et de conclusion, ainsi que la révision et l’artefact.

La séparation avec l’environnement est décisive. GitHub indique que concurrency et environment ne sont pas connectés : la valeur de concurrence peut être n’importe quelle chaîne, et un autre workflow utilisant le même environnement sans ce groupe ne lui est pas soumis. Les protections de l’environnement et la concurrence sont deux surfaces de configuration. Aucune ne se transforme automatiquement en verrou universel de l’autre.

L’API des groupes de concurrence peut exposer des membres actifs et leurs statuts pending ou in progress. C’est une observation utile de la plateforme, pas le relevé complet d’un système cible. Daniel Kade recommande donc de conserver la configuration et la clé développée, la politique de file et d’annulation, les membres et leurs temps, source et artefact, environnement, preuve d’exécution puis une observation cible datée. Les détails sensibles peuvent être protégés ; les liens absents ne doivent pas être imaginés.

Sources

  1. GitHub Docs — Concurrency
  2. GitHub Docs — Workflow syntax
  3. GitHub Docs — Deploying with GitHub Actions
  4. GitHub Docs — Actions concurrency groups REST API