[72] Correction ci

justine commented

2026-09-09 14:32:21 +00:00

Member

Ce que ça change

Les tâches terraform et checkov ne travaillaient pas quand il fallait : elles démarraient sur chaque demande de fusion et tournaient en entier, si bien qu'une correction de CSS téléchargeait Terraform et rougissait sur une
faute d'infrastructure arrivée par quelqu'un d'autre. Elles démarrent toujours — c'est ce qui rend le blocage possible — mais leurs étapes se désistent désormais quand la demande ne touche à rien de Terraform ; et les huit
constats que checkov levait sur stockage.tf portent maintenant leur motif, écrit sur la ressource.

Closes #72

Preuve

$ tests/ci/test-terraform-touche.sh
ok une poussée hors demande de fusion contrôle tout
ok une demande sans branche de base connue contrôle tout
ok une base introuvable contrôle tout, au lieu de se taire
ok une demande qui ne touche que README se désiste
ok « infra/terraform/main.tf » réveille les tâches Terraform (+ 6 autres chemins)
ok un seul fichier Terraform au milieu d'autres suffit à réveiller les tâches
Le désistement des tâches Terraform ne rend « non » que sur un diff obtenu et vide.

$ checkov --directory infra/terraform --config-file infra/terraform/.checkov.yml --compact
Passed checks: 9, Failed checks: 0, Skipped checks: 9 # code 0, rapport JUnit produit

$ tests/ci/test-garde-terraform.sh # CKV_AZURE_59 n'a PAS été éteinte ailleurs
ok checkov nomme CKV_AZURE_59, la règle sur l'accès public au stockage
2 garde(s) éprouvée(s) : le fichier fautif est bien refusé.

$ terraform fmt -check -recursive infra/terraform && tflint --chdir=infra/terraform && echo OK
OK

Les treize autres bancs sont inchangés ; actionlint, shellcheck, yamllint et zizmor sont propres sur ci.yml.

Si ça touche infra/terraform/

Le plan est vide. Ce travail n'ajoute aucun argument Terraform : seulement des commentaires #checkov:skip=… et leur justification. Aucune propriété Azure ne change, il n'y a donc rien à appliquer — mais la trace reste due, et
c'est justement elle qui prouve que le plan est bien vide.

terraform plan -out=tfplan ci-dessous, avant la fusion — attendu : No changes.
terraform apply tfplan — sans objet, le plan ne porte aucun changement
Le pair a relu le plan, pas seulement le code

Relecture

Un pair a relu et laissé un commentaire, même court
Ses remarques sont traitées, ou une réponse explique pourquoi elles ne le sont pas

Ce qui suit le code

docs/runbooks/ mis à jour, un geste d'exploitation a changé — ci.md : sous-section « Le désistement », et l'état des exceptions checkov

Où regarder en priorité

Le sens du doute dans terraform-touche.sh. Un « oui » de trop coûte deux minutes d'exécuteur ; un « non » de trop laisse fusionner une faute d'infrastructure sous une tâche verte, que personne ne verra puisqu'il n'y a rien
à voir. Tout ce qui n'est pas un diff obtenu et vide vaut donc « on contrôle tout ». C'est ce que tient le banc.
Les huit exceptions sont sur la ressource, pas dans .checkov.yml. Une exception globale éteindrait la règle pour la ressource que quelqu'un ajoutera demain sans le savoir. Deux d'entre elles sont marquées DÉCISION OUVERTE
et non « refus » : CKV2_AZURE_38 (suppression réversible) et CKV2_AZURE_41 (expiration des SAS, qui appartient au #70). Je n'ai rien tranché à leur place — à confirmer que c'est bien le partage voulu.
CKV2_AZURE_21 a déménagé. Elle était globale au #72, au motif que « ce dépôt ne gère aucun compte de stockage » ; le #69 a adopté le compte, ce motif est devenu faux, la règle lève toujours. Elle est désormais posée sur le
conteneur d'archive.tf avec un motif vérifiable. .checkov.yml ne porte plus aucune exception globale.

Hors périmètre, mais à savoir : shellcheck échoue déjà sur develop (tests/ci/test-supervision.sh:495, SC2034), la tâche meta est donc rouge pour tout le monde. Je ne l'ai pas touché.

Ce que ça change Les tâches terraform et checkov ne travaillaient pas quand il fallait : elles démarraient sur chaque demande de fusion et tournaient en entier, si bien qu'une correction de CSS téléchargeait Terraform et rougissait sur une faute d'infrastructure arrivée par quelqu'un d'autre. Elles démarrent toujours — c'est ce qui rend le blocage possible — mais leurs étapes se désistent désormais quand la demande ne touche à rien de Terraform ; et les huit constats que checkov levait sur stockage.tf portent maintenant leur motif, écrit sur la ressource. Closes #72 Preuve $ tests/ci/test-terraform-touche.sh ok une poussée hors demande de fusion contrôle tout ok une demande sans branche de base connue contrôle tout ok une base introuvable contrôle tout, au lieu de se taire ok une demande qui ne touche que README se désiste ok « infra/terraform/main.tf » réveille les tâches Terraform (+ 6 autres chemins) ok un seul fichier Terraform au milieu d'autres suffit à réveiller les tâches Le désistement des tâches Terraform ne rend « non » que sur un diff obtenu et vide. $ checkov --directory infra/terraform --config-file infra/terraform/.checkov.yml --compact Passed checks: 9, Failed checks: 0, Skipped checks: 9 # code 0, rapport JUnit produit $ tests/ci/test-garde-terraform.sh # CKV_AZURE_59 n'a PAS été éteinte ailleurs ok checkov nomme CKV_AZURE_59, la règle sur l'accès public au stockage 2 garde(s) éprouvée(s) : le fichier fautif est bien refusé. $ terraform fmt -check -recursive infra/terraform && tflint --chdir=infra/terraform && echo OK OK Les treize autres bancs sont inchangés ; actionlint, shellcheck, yamllint et zizmor sont propres sur ci.yml. Si ça touche infra/terraform/ Le plan est vide. Ce travail n'ajoute aucun argument Terraform : seulement des commentaires #checkov:skip=… et leur justification. Aucune propriété Azure ne change, il n'y a donc rien à appliquer — mais la trace reste due, et c'est justement elle qui prouve que le plan est bien vide. terraform plan -out=tfplan ci-dessous, avant la fusion — attendu : No changes. terraform apply tfplan — sans objet, le plan ne porte aucun changement Le pair a relu le plan, pas seulement le code Relecture Un pair a relu et laissé un commentaire, même court Ses remarques sont traitées, ou une réponse explique pourquoi elles ne le sont pas Ce qui suit le code docs/runbooks/ mis à jour, un geste d'exploitation a changé — ci.md : sous-section « Le désistement », et l'état des exceptions checkov Où regarder en priorité Le sens du doute dans terraform-touche.sh. Un « oui » de trop coûte deux minutes d'exécuteur ; un « non » de trop laisse fusionner une faute d'infrastructure sous une tâche verte, que personne ne verra puisqu'il n'y a rien à voir. Tout ce qui n'est pas un diff obtenu et vide vaut donc « on contrôle tout ». C'est ce que tient le banc. Les huit exceptions sont sur la ressource, pas dans .checkov.yml. Une exception globale éteindrait la règle pour la ressource que quelqu'un ajoutera demain sans le savoir. Deux d'entre elles sont marquées DÉCISION OUVERTE et non « refus » : CKV2_AZURE_38 (suppression réversible) et CKV2_AZURE_41 (expiration des SAS, qui appartient au #70). Je n'ai rien tranché à leur place — à confirmer que c'est bien le partage voulu. CKV2_AZURE_21 a déménagé. Elle était globale au #72, au motif que « ce dépôt ne gère aucun compte de stockage » ; le #69 a adopté le compte, ce motif est devenu faux, la règle lève toujours. Elle est désormais posée sur le conteneur d'archive.tf avec un motif vérifiable. .checkov.yml ne porte plus aucune exception globale. Hors périmètre, mais à savoir : shellcheck échoue déjà sur develop (tests/ci/test-supervision.sh:495, SC2034), la tâche meta est donc rouge pour tout le monde. Je ne l'ai pas touché.

justine added 2 commits

2026-09-09 14:32:21 +00:00

ci : les tâches Terraform se désistent quand la demande n'y touche pas (#72 ) 213f239ee2

CE QUI N'ALLAIT PAS. Les tâches « terraform » et « checkov » vivent dans ci.yml,
et non dans un workflow filtré par `on.paths`, pour que le joker
« Intégration / * » les rende vraiment bloquantes -- un workflow filtré ne
démarre pas, n'écrit aucun statut, et laisserait un contrôle requis « en
attente » pour toujours. Mais elles tournaient EN ENTIER sur chaque demande de
fusion : une correction de CSS téléchargeait Terraform, TFLint et checkov, et
rougissait sur une faute d'infrastructure arrivée par quelqu'un d'autre. Un
contrôle qui accuse une personne du travail d'une autre se fait désarmer dans la
semaine.

LA MOITIÉ MANQUANTE. .forgejo/scripts/terraform-touche.sh. La tâche démarre
toujours -- le statut est écrit, le joker satisfait -- et ce sont ses ÉTAPES qui
se désistent quand la demande ne touche à rien de Terraform. C'est la doctrine du
reste de ci.yml ; seule la question posée change : non plus « ce dépôt
contient-il du Terraform » mais « CETTE DEMANDE y touche-t-elle ».

Réveillent les deux tâches : infra/terraform/, les fixtures fautives, les deux
bancs, le script lui-même et ci.yml.

IL RÉPOND « OUI » DÈS QU'IL DOUTE. Un « oui » de trop coûte deux minutes
d'exécuteur ; un « non » de trop laisse fusionner une faute d'infrastructure sous
une tâche VERTE, que personne ne verra puisqu'il n'y a rien à voir. Événement
hors demande de fusion, GITHUB_BASE_REF vide, git diff en erreur : tout vaut
« on contrôle tout ». Le seul « non » possible est celui d'un diff réellement
obtenu et réellement vide.

D'où le `fetch-depth: 0` sur les deux checkouts concernés : sans historique
complet, « origin/<base> » n'existe pas localement et la comparaison échoue. Le
retirer rend la chaîne lente, pas aveugle -- mais lente pour rien. 586 commits,
4,5 Mo.

tests/ci/test-terraform-touche.sh tient les deux moitiés, en douze cas d'essai
sur un dépôt jetable : poussée hors demande, base vide, base introuvable, chacun
des chemins concernés, un fichier concerné noyé parmi d'autres, et le seul cas
qui doit rendre « non ». Joué par la tâche « repo ».

Mesuré : les douze cas passent, les treize autres bancs sont inchangés,
actionlint, shellcheck, yamllint et zizmor sont propres, et le banc d'hygiène
compte trente-sept noms de contrôle qui correspondent tous.

Manuel d'exploitation : docs/runbooks/ci.md, section « Terraform et sécurité
IaC », nouvelle sous-section « Le désistement ».

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Cc9tidxhXLh4pyLxVar8es

terraform : les neuf constats de checkov portent leur motif, écrit sur la ressource (#72 )

Intégration / Tableau de bord — dépendances, tests et construction (pull_request) Successful in 48s

Details

Intégration / Contrôles statiques du dépôt (pull_request) Successful in 7s

Details

Intégration / Terraform — format, validité et lint (pull_request) Successful in 23s

Details

Intégration / Checkov — audit de la configuration (pull_request) Successful in 48s

Details

Intégration / Workflows — lint et audit de sécurité (pull_request) Failing after 25s

Details

Infra Ansible / Playbooks Ansible valides (pull_request) Successful in 1m59s

Details

Intégration / Python — qualité, tests et dépendances (pull_request) Successful in 5m58s

Details

bdd2d80b31

La chaîne était rouge sur huit constats visant `azurerm_storage_account.archive`,
arrivé avec le #69 après que le #72 eut posé l'audit. Aucun n'était un défaut de
la chaîne : checkov faisait exactement ce qu'on lui demande.

SIX SONT DES REFUS DE L'ABONNEMENT OU DU RÔLE, et le fichier les développait
déjà, en toutes lettres, sans que checkov puisse le lire :

  CKV_AZURE_59  / CKV2_AZURE_33  point de terminaison privé impossible ; mettre
                                 public_network_access_enabled à false couperait
                                 le terraform init qui lit l'état DANS ce compte
  CKV2_AZURE_40                  shared_access_key_enabled reste true, le #70 en
                                 a besoin
  CKV_AZURE_206                  Standard_LRS est ce que bootstrap.sh a créé et
                                 ce que ce fichier adopte ; le géo-redondant
                                 doublerait le coût contre le plafond de l'ADR 0012
  CKV_AZURE_33                   aucun service Queue n'est utilisé
  CKV2_AZURE_1                   le chiffrement par clé gérée exige un Key Vault,
                                 hors du rôle Devops-cours-projet-eadl

DEUX SONT DES DÉCISIONS OUVERTES, marquées comme telles et non comme des refus :
CKV2_AZURE_38 (suppression réversible) et CKV2_AZURE_41 (expiration des jetons
SAS, qui appartient au #70). Elles se retireront dans le même geste que la
propriété qui les remplacera. Rien n'est décidé ici à la place de ces tickets :
ce commit ne change aucune propriété Azure, seulement des commentaires — le plan
est vide.

SUR LA RESSOURCE, PAS DANS .checkov.yml. Une exception globale éteint la règle
pour tout le dépôt, y compris pour la ressource que quelqu'un ajoutera demain
sans savoir qu'elle est éteinte. Le fichier global reste réservé à ce qui est
inapplicable partout — et il ne contient plus rien du tout.

CAR L'EXCEPTION GLOBALE DU #72 AVAIT EXPIRÉ. CKV2_AZURE_21 y était écartée au
motif que « ce dépôt ne gère aucun compte de stockage ». Le #69 a adopté le
compte : le motif est devenu faux, alors que la règle lève toujours, sur le
conteneur d'archive. Une exception dont la justification a expiré est le pire des
deux mondes — elle éteint largement, et son motif n'apprend rien. Déplacée sur le
conteneur dans archive.tf, avec un motif à jour et vérifiable : l'espace Log
Analytics qu'elle réclame n'est pas créable avec le rôle disponible. Le « À
REVOIR le jour où un compte de stockage est réellement déclaré ici » qu'elle
portait aura servi exactement à cela.

CE QUE CELA N'A PAS ÉTEINT, et c'est le contrôle à faire en relecture : une
exception posée sur une ressource ne vaut que pour elle. CKV_AZURE_59 est écartée
sur ce compte-là et reste vivante partout ailleurs — tests/ci/test-garde-
terraform.sh la rejoue sur le fichier fautif et passe toujours. Si quelqu'un
avait glissé ces huit lignes dans .checkov.yml, ce banc serait rouge.

Mesuré : checkov rend « 9 réussis, 0 en échec, 9 sautés », code 0, rapport JUnit
produit ; terraform fmt et tflint passent ; les treize autres bancs sont
inchangés. Ce commit n'ajoute aucun argument Terraform, seulement des
commentaires : fmt et tflint, qui analysent le HCL en entier, en sont la preuve.

Manuel d'exploitation : docs/runbooks/ci.md, « Que faire quand une tâche
bloque », état des exceptions.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Cc9tidxhXLh4pyLxVar8es

justine changed title from ~~justine/72-garde-terraform-desistement~~ to [72] Correction ci

2026-09-09 14:32:35 +00:00

justine requested review from lenaic

2026-09-09 14:32:48 +00:00

justine self-assigned this

2026-09-09 14:32:49 +00:00

justine added 1 commit

2026-09-09 14:40:09 +00:00

ci : shellcheck ne bloque plus la chaîne sur une variable qui fonctionne

Intégration / Tableau de bord — dépendances, tests et construction (pull_request) Successful in 48s

Details

Intégration / Contrôles statiques du dépôt (pull_request) Successful in 7s

Details

Intégration / Terraform — format, validité et lint (pull_request) Successful in 25s

Details

Intégration / Workflows — lint et audit de sécurité (pull_request) Successful in 18s

Details

Intégration / Checkov — audit de la configuration (pull_request) Successful in 47s

Details

Infra Ansible / Playbooks Ansible valides (pull_request) Successful in 1m7s

Details

Intégration / Python — qualité, tests et dépendances (pull_request) Successful in 5m48s

Details

b61a95a17d

L'étape « shellcheck sur nos propres scripts » de la tâche « meta » était rouge
sur develop, donc la chaîne l'était pour tout le monde :

  tests/ci/test-supervision.sh:495
  SC2034 (warning): OPS_TEXTFILE_DIR appears unused.

L'avertissement est un faux positif, mais un faux positif explicable et non un
bruit à faire taire. La variable EST lue : `ops_publier_volumetrie` vient d'être
sourcée depuis bin/_metriques-ops.sh, qui la pose à la ligne 38 et la relit à
chaque écriture. shellcheck, lui, ne suit pas un source dynamique -- SC1090 est
désactivé deux lignes plus haut, précisément pour cela -- si bien qu'il ne voit
qu'une affectation jamais relue dans ce fichier.

Le remède est celui que shellcheck propose lui-même dans son message, « or
export if used externally » : un `export`, qui ne change rien au comportement et
dit ce qui se passe. Préféré à un `# shellcheck disable=SC2034`, qui aurait
masqué la classe entière dans ce fichier pour une seule ligne.

Mesuré : `shellcheck .forgejo/scripts/*.sh tests/ci/*.sh` -- la commande exacte
de l'étape -- rend 0. Le banc se comporte à l'identique, et ses quatre
assertions sur la volumétrie passent, dont « un résumé bien formé devient une
métrique », qui lit le fichier écrit dans le bac jetable et prouve donc que la
variable est bien prise en compte.

Sans rapport avec le #72, corrigé au passage parce qu'aucune demande de fusion
ne pouvait devenir verte tant que cette étape échouait.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Cc9tidxhXLh4pyLxVar8es

justine added 1 commit

2026-09-09 14:45:26 +00:00

Merge remote-tracking branch 'origin/develop' into justine/72-garde-terraform-desistement

Intégration / Contrôles statiques du dépôt (pull_request) Successful in 11s

Details

Intégration / Tableau de bord — dépendances, tests et construction (pull_request) Successful in 46s

Details

Intégration / Terraform — format, validité et lint (pull_request) Successful in 24s

Details

Intégration / Workflows — lint et audit de sécurité (pull_request) Successful in 19s

Details

Intégration / Checkov — audit de la configuration (pull_request) Successful in 50s

Details

Intégration / Python — qualité, tests et dépendances (pull_request) Successful in 5m57s

Details

2a28099021

# Conflicts:
#	tests/ci/test-supervision.sh

justine requested review from gabriel

2026-09-09 14:45:50 +00:00

gabriel merged commit f5da7052c8 into develop

2026-09-09 14:47:08 +00:00

gabriel deleted branch justine/72-garde-terraform-desistement

2026-09-09 14:47:08 +00:00

gabriel referenced this pull request from a commit

2026-09-09 14:47:09 +00:00

Merge pull request '[72] Correction ci' (#251) from justine/72-garde-terraform-desistement into develop

Rows
Columns

[72] Correction ci #251