ci : toute demande de fusion touchant Terraform est validée et auditée, sans Azure (#72) #242
No reviewers
Labels
No labels
Compat/Breaking
EC01
EC02
EC03
EC04
EC05
EC06
Kind/BDD
Kind/Back
Kind/Bug
Kind/CICD
Kind/Cloud
Kind/Contenu
Kind/Data
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Front
Kind/IA
Kind/Infra
Kind/Monitoring
Kind/Security
Kind/Testing
Portée/Post-jury
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
ops/alerte
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
g2/enervision!242
Loading…
Reference in a new issue
No description provided.
Delete branch "justine/72-garde-terraform"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Ce que ça change
Deux tâches de plus dans Intégration — terraform (fmt, validate, tflint) et checkov — qui valident et auditent infra/terraform/ sans jamais joindre Azure : init -backend=false, aucun secret, aucune variable ARM_*. Elles sont
dans ci.yml plutôt que dans un workflow filtré par on.paths, parce qu'un workflow filtré ne démarre pas, n'écrit donc aucun statut, et laisserait un contrôle requis « en attente » pour toujours sur les demandes de fusion qui
ne touchent pas Terraform : ici elles tombent sous le joker Intégration / * déjà déclaré, et bloquent vraiment.
Closes #72
Preuve
$ terraform fmt -check -recursive -diff infra/terraform && echo OK
OK
$ terraform -chdir=infra/terraform init -backend=false -input=false # sans az login
Terraform has been successfully initialized!
$ terraform -chdir=infra/terraform validate
Success! The configuration is valid.
$ tflint --chdir=infra/terraform && echo OK
OK
$ checkov --directory infra/terraform --config-file infra/terraform/.checkov.yml --compact
Passed checks: 2, Failed checks: 0, Skipped checks: 0
$ tests/ci/test-garde-terraform.sh # la chaîne mord-elle encore ?
ok terraform fmt refuse le fichier mal formaté (code 3)
ok terraform fmt nomme le fichier en cause
ok checkov refuse la ressource fautive (code 1)
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é.
$ tests/ci/test-hygiene-workflows.sh | tail -4
ok chacun des 6 jobs de la CI rend un résumé
ok les 36 noms de contrôle complétés correspondent tous à un contrôle réellement rapporté
ok chaque banc shell sous tests/ci est joué par ci.yml
Les workflows sont lisibles, épinglés, à privilège minimal et s'expliquent d'eux-mêmes.
actionlint, shellcheck, zizmor et yamllint sont propres sur ci.yml. Le journal d'un passage rouge puis vert sur la forge est à ajouter ici une fois la branche poussée.
Relecture
Ce qui suit le code
Où regarder en priorité
Pas de section infra/terraform/ ci-dessus, et c'est voulu : cette demande n'ajoute aucun .tf. Les trois fichiers posés sous infra/terraform/ (.checkov.yml, .tflint.hcl, requirements-ci.txt) sont de la configuration d'outillage
— rien à plan, rien à apply, aucune ressource Azure touchée.
Trois points où un second avis aide :
unique, donc ça s'ajoute à la file. C'est le prix du blocage réel, à valider.
par bootstrap.sh au #67).
».
Relu, rien de bloquant : approuvé.
Relecture volontairement resserrée sur le bloquant et le critique (fin de projet).
Ce que j'ai vérifié, pas seulement lu
Intégration / *comme seul contrôle requis, surdevelopet surmain: les deux tâches rapatriées bloquent réellement, sans rien à configurer sur la forge. L'argument « workflow filtré = contrôle en attente pour toujours » est donc juste, et le choix de les mettre dansci.ymlest le bon.ed0c86b, en une seule exécution (n° 658, aucune relance) — le statut n'est pas dans le cas où l'API raconte l'état d'avant. Les tâchesTerraform(2 min 47) etCheckov(3 min 47) ont donc réellement téléchargé, vérifié les sommes de contrôle et joué leurs bancs.tests/ci/test-hygiene-workflows.shrejoué sur la branche : passe, dont « les 36 noms de contrôle complétés correspondent tous à un contrôle réellement rapporté » et « chaque banc shell soustests/ciest joué parci.yml».shellcheckpropre sur le nouveau banc, enregistré100755.terraform fmtsort en code 3 et nommemauvais.tf.terraform fmt -check -recursive infra/terraformest propre.required_version = ">= 1.9"accepte bien le1.16.1épinglé, et-backend=falseécarte le blocbackend "azurerm"— aucun contact Azure, conforme à ce qu'annonce la demande.${{ }}venant d'une entrée non maîtrisée dans lesrun:, actions épinglées par SHA sur exactement les mêmes pins que le reste du fichier,persist-credentials: false.Sur les trois points où tu demandais un second avis : le coût est assumé et documenté, l'exception
CKV2_AZURE_21est vérifiable dans le dépôt (le compte de stockage n'est effectivement pas géré ici, seul le conteneur l'est), et la consigne sur la fixture est claire — le commentaire en tête du fichier suffit.Trois remarques non bloquantes, pour plus tard
checkov --directory ... --config-file ... --compact, sans--output junitxml --output-file-path console,rapport-checkov.xml. Si checkov traite ce chemin comme un répertoire plutôt que comme un fichier, l'artefact repart vide en silence —if-no-files-found: ignoreetcontinue-on-error: trueétouffent le cas. Un coup d'œil au contenu de l'artefact du passage 658 lève le doute en une minute.missingquand le téléchargement de Terraform échoue, alors que la doctrine de l'étape est « avertir et nommer ce qui n'a pas été contrôlé ». Purement cosmétique —renderne fait jamais rougir la tâche — maiswarneddirait la vérité, comme les deux autres contrôles juste au-dessus.mypydans le commentaire deCHECKOV_BLOQUANT(et dans la même phrase du runbook) : ça se lit comme un report de copie, la bascule décrite porte sur checkov.Rien de tout cela ne justifie de retenir la fusion.