ci — arrêter les runs qui ne peuvent pas aboutir, et le doublon push+PR
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
This commit is contained in:
@@ -2,12 +2,15 @@
|
|||||||
# template source: https://github.com/bretfisher/docker-build-workflow/blob/main/templates/call-docker-build.yaml
|
# template source: https://github.com/bretfisher/docker-build-workflow/blob/main/templates/call-docker-build.yaml
|
||||||
name: Crowdsec
|
name: Crowdsec
|
||||||
|
|
||||||
on: #[push,pull_request]
|
# À LA DEMANDE, et seulement à la demande — comme minio.yaml : auth Vault par
|
||||||
|
# flux OIDC (un humain doit ouvrir un lien) et apply `auto_approve` contre la prod.
|
||||||
|
#
|
||||||
|
# Note : les triggers `push`/`pull_request` retirés ici étaient de toute façon
|
||||||
|
# INERTES — ils passaient par une ancre YAML (`&`/`*`), que le parseur
|
||||||
|
# d'événements de Gitea ne résout pas (vécu sur arcodange/kadans, issues 113
|
||||||
|
# → 117). Ce workflow ne partait déjà qu'à la main ; c'est maintenant écrit.
|
||||||
|
on:
|
||||||
workflow_dispatch: {}
|
workflow_dispatch: {}
|
||||||
push: &crowdsecPaths
|
|
||||||
paths:
|
|
||||||
- 'crowdsec/**/*.tf'
|
|
||||||
pull_request: *crowdsecPaths
|
|
||||||
|
|
||||||
# cancel any previously-started, yet still active runs of this workflow on the same branch
|
# cancel any previously-started, yet still active runs of this workflow on the same branch
|
||||||
concurrency:
|
concurrency:
|
||||||
|
|||||||
@@ -2,14 +2,32 @@
|
|||||||
# template source: https://github.com/bretfisher/docker-build-workflow/blob/main/templates/call-docker-build.yaml
|
# template source: https://github.com/bretfisher/docker-build-workflow/blob/main/templates/call-docker-build.yaml
|
||||||
name: Helm Charts
|
name: Helm Charts
|
||||||
|
|
||||||
on: [push,pull_request,workflow_dispatch]
|
# Celui-ci travaille SEUL (pas d'auth Vault, pas d'apply) : on le garde
|
||||||
# push: &helmPaths # turns out gitea don't handle well the paths filter
|
# automatique. Mais `push` sur TOUTES les branches + `pull_request` faisait
|
||||||
# paths:
|
# partir DEUX runs pour le même commit dès qu'une branche avait une PR.
|
||||||
# - '*/\.yaml'
|
#
|
||||||
# - '*/\.tpl'
|
# Même forme que la CI de kadans : la branche est couverte par `pull_request`,
|
||||||
# - '*/NOTES.txt'
|
# `main` par le `push` d'après-merge. Un run par événement, aucun angle mort.
|
||||||
# - '*/\.helmignore'
|
#
|
||||||
# pull_request: *helmPaths
|
# (Le filtre de chemins d'origine, resté en commentaire des années sous un
|
||||||
|
# « gitea don't handle well the paths filter », n'était probablement pas en
|
||||||
|
# cause : il passait par une ancre YAML, et le parseur d'événements de Gitea ne
|
||||||
|
# les résout pas — issues 113 → 117 de kadans. Le job `filter-chart` fait déjà
|
||||||
|
# ce tri au niveau job, donc on n'y retouche pas.)
|
||||||
|
#
|
||||||
|
# ⚠ Chaque clé 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. On copie la forme qui tourne (kadans
|
||||||
|
# ci.yml), listes dupliquées à la main, sans ancre.
|
||||||
|
on:
|
||||||
|
workflow_dispatch: {}
|
||||||
|
push:
|
||||||
|
branches: [main]
|
||||||
|
paths-ignore:
|
||||||
|
- '**.md'
|
||||||
|
pull_request:
|
||||||
|
paths-ignore:
|
||||||
|
- '**.md'
|
||||||
|
|
||||||
# cancel any previously-started, yet still active runs of this workflow on the same branch
|
# cancel any previously-started, yet still active runs of this workflow on the same branch
|
||||||
concurrency:
|
concurrency:
|
||||||
|
|||||||
+11
-12
@@ -1,20 +1,19 @@
|
|||||||
---
|
---
|
||||||
name: MinIO
|
name: MinIO
|
||||||
|
|
||||||
# ⚠ Triggers écrits EN TOUTES LETTRES, sans ancre YAML (`&`/`*`).
|
# À LA DEMANDE, et seulement à la demande. Deux raisons, chacune suffisante :
|
||||||
# Une ancre dans un trigger Gitea Actions fait taire push ET pull_request —
|
#
|
||||||
# en silence, aucun run, aucune erreur (vécu sur arcodange/kadans, issues 113
|
# 1. Ce workflow ne PEUT PAS aboutir sans un humain : l'auth Vault passe par
|
||||||
# → 117). Les autres workflows de ce repo utilisent encore des ancres : à
|
# un flux OIDC dont le lien doit être ouvert dans un navigateur connecté.
|
||||||
# vérifier séparément, c'est probablement pour ça qu'ils ne partent qu'à la
|
# Déclenché tout seul, il occupe un runner jusqu'à son timeout — et retarde
|
||||||
# main (workflow_dispatch).
|
# les runs que quelqu'un attend vraiment.
|
||||||
|
# 2. Il fait `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.
|
||||||
|
#
|
||||||
|
# Au passage : `push` (toutes branches) + `pull_request` faisait partir DEUX runs
|
||||||
|
# par commit d'une branche en PR — le même SHA, deux fois.
|
||||||
on:
|
on:
|
||||||
workflow_dispatch: {}
|
workflow_dispatch: {}
|
||||||
push:
|
|
||||||
paths:
|
|
||||||
- 'minio/**/*.tf'
|
|
||||||
pull_request:
|
|
||||||
paths:
|
|
||||||
- 'minio/**/*.tf'
|
|
||||||
|
|
||||||
# cancel any previously-started, yet still active runs of this workflow on the same branch
|
# cancel any previously-started, yet still active runs of this workflow on the same branch
|
||||||
concurrency:
|
concurrency:
|
||||||
|
|||||||
@@ -2,12 +2,14 @@
|
|||||||
# template source: https://github.com/bretfisher/docker-build-workflow/blob/main/templates/call-docker-build.yaml
|
# template source: https://github.com/bretfisher/docker-build-workflow/blob/main/templates/call-docker-build.yaml
|
||||||
name: Plausible
|
name: Plausible
|
||||||
|
|
||||||
on: #[push,pull_request]
|
# À LA DEMANDE, et seulement à la demande — comme minio.yaml : auth Vault par
|
||||||
|
# flux OIDC (un humain doit ouvrir un lien) et apply `auto_approve` contre la prod.
|
||||||
|
#
|
||||||
|
# Note : les triggers `push`/`pull_request` retirés ici étaient de toute façon
|
||||||
|
# INERTES (ancre YAML non résolue par Gitea, issues 113 → 117 de kadans). Ce
|
||||||
|
# workflow ne partait déjà qu'à la main ; c'est maintenant écrit.
|
||||||
|
on:
|
||||||
workflow_dispatch: {}
|
workflow_dispatch: {}
|
||||||
push: &plausiblePaths
|
|
||||||
paths:
|
|
||||||
- 'plausible/**/*.tf'
|
|
||||||
pull_request: *plausiblePaths
|
|
||||||
|
|
||||||
# cancel any previously-started, yet still active runs of this workflow on the same branch
|
# cancel any previously-started, yet still active runs of this workflow on the same branch
|
||||||
concurrency:
|
concurrency:
|
||||||
|
|||||||
+10
-15
@@ -2,23 +2,18 @@
|
|||||||
# template source: https://github.com/bretfisher/docker-build-workflow/blob/main/templates/call-docker-build.yaml
|
# template source: https://github.com/bretfisher/docker-build-workflow/blob/main/templates/call-docker-build.yaml
|
||||||
name: Hashicorp Vault
|
name: Hashicorp Vault
|
||||||
|
|
||||||
# ⚠ Triggers écrits EN TOUTES LETTRES, sans ancre YAML (`&`/`*`) : une ancre
|
# À LA DEMANDE, et seulement à la demande — comme minio.yaml, et pour les mêmes
|
||||||
# dans un trigger Gitea Actions fait taire push ET pull_request, en silence
|
# deux raisons : l'auth Vault exige qu'un humain ouvre un lien OIDC (sans lui, le
|
||||||
# (vécu sur arcodange/kadans, issues 113 → 117) — c'est probablement pourquoi
|
# run squatte un runner jusqu'au timeout), et l'apply se fait en `auto_approve`
|
||||||
# ce workflow ne partait qu'à la main.
|
# contre la prod.
|
||||||
# Et `*.tfvars` compte AUTANT que `*.tf` : la liste des applications (donc les
|
#
|
||||||
# rôles gitea_cicd_<app>) vit dans terraform.tfvars — l'oublier, c'est ajouter
|
# ⚠ Ce qui change AUSSI de nature : `hashicorp-vault/**/*.tfvars` compte autant
|
||||||
# une app sans jamais créer son rôle.
|
# que `*.tf` — la liste des applications (donc les rôles gitea_cicd_<app>) vit
|
||||||
|
# dans terraform.tfvars. Ce n'est plus un filtre de chemins mais ça reste vrai
|
||||||
|
# du POURQUOI on relance : ajouter une app au tfvars sans relancer ce workflow,
|
||||||
|
# c'est une app sans rôle CI.
|
||||||
on:
|
on:
|
||||||
workflow_dispatch: {}
|
workflow_dispatch: {}
|
||||||
push:
|
|
||||||
paths:
|
|
||||||
- 'hashicorp-vault/**/*.tf'
|
|
||||||
- 'hashicorp-vault/**/*.tfvars'
|
|
||||||
pull_request:
|
|
||||||
paths:
|
|
||||||
- 'hashicorp-vault/**/*.tf'
|
|
||||||
- 'hashicorp-vault/**/*.tfvars'
|
|
||||||
|
|
||||||
# cancel any previously-started, yet still active runs of this workflow on the same branch
|
# cancel any previously-started, yet still active runs of this workflow on the same branch
|
||||||
concurrency:
|
concurrency:
|
||||||
|
|||||||
Reference in New Issue
Block a user