Ce matin, quatre runs d'une branche déjà mergée et supprimée ont bloqué l'apply qu'on attendait. Deux causes indépendantes, les deux réparées ici.
1. Des workflows qui ne peuvent pas aboutir seuls
minio, vault, crowdsec, plausible s'authentifient à Vault par un flux OIDC dont un humain doit ouvrir le lien. Déclenchés automatiquement, ils ne peuvent rien faire d'autre qu'occuper un runner jusqu'à leur timeout — en retardant les runs que quelqu'un attend.
Et ils font terraform apply en auto_approve contre la prod. Se déclencher sur le push d'une branche, c'est appliquer du code que personne n'a relu — un défaut plus grave que l'encombrement.
→ workflow_dispatch seul. Ça ne retire pas une capacité : ça écrit ce qu'ils faisaient déjà.
Au passage, crowdsec et plausible passaient de toute façon par une ancre YAML : leurs triggers étaient inertes (issues 113 → 117 de kadans). Le commentaire de minio.yaml le soupçonnait ; c'est confirmé.
2. Le doublon push + pull_request
push sur toutes les branches pluspull_request fait partir deux runs par commit dès qu'une branche a une PR. Vérifié sur les runs de ce matin : 258/259 et 260/261 portent le même SHA e8ab199.
helmcharts travaille seul (pas d'auth, pas d'apply) et mérite de rester automatique — il prend donc la forme éprouvée de la CI de kadans : push sur main, pull_request pour la branche. Un run par événement, aucun angle mort.
Le détail qui compte
Chaque clé de trigger porte un corps explicite. Un pull_request: nu (valeur nulle) n'est pas une forme éprouvée sur ce Gitea, et son mode d'échec est le silencieux — aucun run, aucune erreur, comme les ancres. Listes dupliquées à la main, c'est le prix.
À vérifier après merge : que la prochaine PR touchant un chart déclenche bien Helm Charts. C'est le seul trigger que cette PR modifie sans le supprimer, donc le seul qui pourrait tomber en silence.
Pendant du même changement côté arcodange/kadans (PR 170).
Ce matin, quatre runs d'une branche **déjà mergée et supprimée** ont bloqué l'apply qu'on attendait. Deux causes indépendantes, les deux réparées ici.
## 1. Des workflows qui ne peuvent pas aboutir seuls
`minio`, `vault`, `crowdsec`, `plausible` s'authentifient à Vault par un flux OIDC dont **un humain doit ouvrir le lien**. Déclenchés automatiquement, ils ne peuvent rien faire d'autre qu'occuper un runner jusqu'à leur timeout — en retardant les runs que quelqu'un attend.
Et ils font `terraform apply` en **`auto_approve` contre la prod**. Se déclencher sur le push d'une branche, c'est appliquer du code que personne n'a relu — un défaut plus grave que l'encombrement.
→ `workflow_dispatch` seul. Ça ne retire pas une capacité : ça **écrit** ce qu'ils faisaient déjà.
Au passage, `crowdsec` et `plausible` passaient de toute façon par une ancre YAML : leurs triggers étaient **inertes** (issues 113 → 117 de kadans). Le commentaire de `minio.yaml` le soupçonnait ; c'est confirmé.
## 2. Le doublon push + pull_request
`push` sur toutes les branches **plus** `pull_request` fait partir **deux runs par commit** dès qu'une branche a une PR. Vérifié sur les runs de ce matin : 258/259 et 260/261 portent le même SHA `e8ab199`.
`helmcharts` travaille seul (pas d'auth, pas d'apply) et mérite de rester automatique — il prend donc la forme éprouvée de la CI de kadans : `push` sur `main`, `pull_request` pour la branche. Un run par événement, aucun angle mort.
## Le détail qui compte
Chaque clé de trigger porte un **corps explicite**. Un `pull_request:` nu (valeur nulle) n'est pas une forme éprouvée sur ce Gitea, et son mode d'échec est le silencieux — aucun run, aucune erreur, comme les ancres. Listes dupliquées à la main, c'est le prix.
**À vérifier après merge** : que la prochaine PR touchant un chart déclenche bien `Helm Charts`. C'est le seul trigger que cette PR modifie sans le supprimer, donc le seul qui pourrait tomber en silence.
Pendant du même changement côté `arcodange/kadans` (PR 170).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA
Quatre runs d'une branche déjà mergée ont bloqué, ce matin, l'apply qu'on
attendait. Deux causes, indépendantes :
1. Les workflows tofu (minio, vault, crowdsec, plausible) s'authentifient à
Vault par un flux OIDC dont un HUMAIN doit ouvrir le lien. Déclenchés tout
seuls, ils ne peuvent qu'occuper un runner jusqu'au timeout. Ils font en
plus `apply` en `auto_approve` CONTRE LA PROD : partir sur le push d'une
branche, c'est appliquer du code que personne n'a relu. → `workflow_dispatch`
seul, ce qui écrit enfin ce qu'ils faisaient déjà.
(crowdsec et plausible passaient de toute façon par une ancre YAML, donc
leurs triggers étaient INERTES — issues 113 → 117 de kadans.)
2. `push` sur toutes les branches + `pull_request` = DEUX runs par commit dès
qu'une branche a une PR. Vérifié : runs 258/259 et 260/261 portent le même
SHA. helmcharts, qui travaille seul et mérite de rester automatique, prend
la forme éprouvée de la CI de kadans : push sur `main`, PR pour la branche.
Chaque clé de trigger porte un corps explicite : un `pull_request:` nu n'est
pas une forme éprouvée ici, et son mode d'échec est le silencieux.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Ce matin, quatre runs d'une branche déjà mergée et supprimée ont bloqué l'apply qu'on attendait. Deux causes indépendantes, les deux réparées ici.
1. Des workflows qui ne peuvent pas aboutir seuls
minio,vault,crowdsec,plausibles'authentifient à Vault par un flux OIDC dont un humain doit ouvrir le lien. Déclenchés automatiquement, ils ne peuvent rien faire d'autre qu'occuper un runner jusqu'à leur timeout — en retardant les runs que quelqu'un attend.Et ils font
terraform applyenauto_approvecontre la prod. Se déclencher sur le push d'une branche, c'est appliquer du code que personne n'a relu — un défaut plus grave que l'encombrement.→
workflow_dispatchseul. Ça ne retire pas une capacité : ça écrit ce qu'ils faisaient déjà.Au passage,
crowdsecetplausiblepassaient de toute façon par une ancre YAML : leurs triggers étaient inertes (issues 113 → 117 de kadans). Le commentaire deminio.yamlle soupçonnait ; c'est confirmé.2. Le doublon push + pull_request
pushsur toutes les branches pluspull_requestfait partir deux runs par commit dès qu'une branche a une PR. Vérifié sur les runs de ce matin : 258/259 et 260/261 portent le même SHAe8ab199.helmchartstravaille seul (pas d'auth, pas d'apply) et mérite de rester automatique — il prend donc la forme éprouvée de la CI de kadans :pushsurmain,pull_requestpour la branche. Un run par événement, aucun angle mort.Le détail qui compte
Chaque clé de trigger porte un corps explicite. Un
pull_request:nu (valeur nulle) n'est pas une forme éprouvée sur ce Gitea, et son mode d'échec est le silencieux — aucun run, aucune erreur, comme les ancres. Listes dupliquées à la main, c'est le prix.À vérifier après merge : que la prochaine PR touchant un chart déclenche bien
Helm Charts. C'est le seul trigger que cette PR modifie sans le supprimer, donc le seul qui pourrait tomber en silence.Pendant du même changement côté
arcodange/kadans(PR 170).🤖 Generated with Claude Code
https://claude.ai/code/session_01CoafGWmRVESaWX819USUUA