ci: fait de la chaîne une barrière (couverture, mypy, dépendances, images) #57
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!57
Loading…
Reference in a new issue
No description provided.
Delete branch "gabriel/40-ci-barriere"
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
La chaîne d'intégration devient une barrière : mypy strict et l'audit des
dépendances applicatives sont réellement bloquants (ils ne l'étaient qu'en
apparence), les seuils de couverture sont armés à 70 % / 85 %, les images
non épinglées font échouer la chaîne, et elle se joue aussi sur
develop.Ref #40
Preuve
Chaque mécanisme a été rejoué hors chaîne, comparé avant/après sur le code
réel du dépôt :
--config-file(config jamais chargée),bloque désormais sur une fonction non annotée.
--cov=servicesne mesurait que les fichiers importés — untest trivial affichait 100 % sur 8 lignes au lieu de 32.
.coveragerccorrige la mesure ; la base réelle est à 27 %, les seuils sont posés à
70 / 85 comme l'exige le ticket, donc le premier test unitaire écrit fera
rougir la chaîne — c'est documenté dans le runbook, pas un bug.
idna==3.6, PYSEC-2024-60/2026-215)puis vert après retrait.
tests/ci/test-verifier-images.sh),l'ancienne expression régulière rejetait
FROM base AS runtime.Il manque la preuve exigée par le ticket lui-même : une dépendance
vulnérable introduite dans cette PR, le journal d'exécution en échec
puis en succès après retrait, à joindre au ticket #40. Je le fais dans un
commit séparé une fois la PR ouverte, avant de demander la relecture.
Relecture
Ce qui suit le code
docs/runbooks/ci.mdmis à jourOù regarder en priorité
demande, alors que la base mesurée est à 27 % : le premier test unitaire
écrit par l'équipe fera rougir la chaîne. C'est assumé et documenté
(section dédiée dans
docs/runbooks/ci.md), mais ça mérite un secondavis avant de fusionner.
actions/upload-artifact@v3n'est pas épinglé à un commit : sur lemiroir d'actions de la forge,
@v3ne résout vers aucun tag de patchconnu, je préfère ne pas pinner à l'aveugle un job qui publie les SBOM.
déclarer les cinq tâches en contrôles obligatoires dans la protection de
branche de
developetmain, avec leur nom affiché (table dans lerunbook) — sans quoi tout ce qui précède reste décoratif.
Relu en entier, scripts et cas d'essai compris. J'ai joué
verifier-images.shsur le compose de la #56 et sur celui de la forge : il accepte les deux, aucun faux positif.Deux choix que je retiens. Les tâches qui tournent toujours pour que seules leurs étapes se sautent, sinon une tâche filtrée par
on.pathsresterait en attente et bloquerait un contrôle obligatoire pour toujours. Et les cas d'essai écrits pour le contrôle d'images avant de s'en servir, ce que personne ne fait spontanément.Un point de fond et trois détails, posés sur les lignes concernées.
@ -14,0 +42,4 @@## Ils ne coûtent rien tant qu'aucun test n'existe : la tâche se saute. Le jour# où le premier test unitaire est écrit, la mesure porte sur tout le code de# « services » et « packages », pas seulement sur ce que ce test importe — etLes seuils de couverture relèvent de l'ENF-10, qualité logicielle, qui les cite mot pour mot. L'ENF-09 est la reproductibilité par Ansible.
@ -60,0 +300,4 @@python -m venv /tmp/venv-applicatif/tmp/venv-applicatif/bin/pip install --quiet -r /tmp/deps-applicatif.txtcyclonedx-py environment /tmp/venv-applicatif --of JSON -o sbom-applicatif.jsonpython -c "import json,sys; d=json.load(open('sbom-applicatif.json')); print(len(d['components']), 'composants applicatifs inventoriés')"L'inventaire des composants relève de l'ENF-11, chaîne d'approvisionnement, avec les images épinglées et le scan bloquant. L'ENF-10 est la qualité logicielle.
@ -0,0 +9,4 @@dessous se lancent **à la racine du dépôt** et ont été exécutées telles quelles.## Les cinq tâches« Les cinq tâches » au-dessus d'un tableau qui en compte six.
@ -0,0 +363,4 @@- une approbation obligatoire, invalidée par toute nouvelle poussée ;- interdiction de la poussée directe ;- contrôles d'état obligatoires — la forge les désigne par le `name:` **affiché**de la tâche, pas par sa clé dans le YAML :Cette section décrit une protection par noms exacts, mais ce n'est pas notre configuration :
developetmainexigent le motifIntégration / *. Tes six tâches sont donc déjà obligatoires sans que personne inscrive quoi que ce soit, et la procédure de renommage en deux temps décrite plus bas n'a pas lieu d'être. Le tableau des six noms peut rester à titre indicatif, mais il faut dire que le motif les couvre tous.Relu en entier, scripts et cas d'essai compris. Les images sont épinglées par empreinte, le contrôle qui le vérifie a ses propres cas d'essai, et les tâches tournent toujours pour que seules leurs étapes se sautent, ce qui évite qu'un contrôle obligatoire reste en attente pour toujours. Les six contrôles sont verts. Le conflit sur l'index des manuels venait de ma demande #60, je l'ai résolu en gardant les deux lignes.
Relu en entier, scripts et cas d'essai compris. Les six contrôles sont verts. Le conflit sur l'index des manuels venait de ma demande #60, résolu en gardant les deux lignes.