Les CI de deux push rapprochés peuvent finir dans le désordre. deploy.yml faisait alors
reset --hard sur un GITHUB_SHA plus ancien que celui déjà déployé, et le groupe concurrency
deploy-<branche> ne garde qu'un job en attente : un troisième arrivé annulait le précédent, qui
n'était jamais déployé.
- un commit qui précède celui déjà déployé est ignoré, avec une annotation dans le run ;
- le groupe concurrency cède la place à un flock posé dans le clone de la VM, tenu du fetch
jusqu'à la sonde de santé : les déploiements passent un par un, aucun n'est annulé ;
- les trois étapes n'en font plus qu'une, le verrou tombant avec le shell qui l'a posé ; les
journaux restent découpés par ::group::.
ADR 0014 et 50-cicd.md décrivent les deux gardes.
Johan LEROY
3ca4839a02