Chaîne d'intégration : 7 min 30 par demande, dont trois fois la même installation #133
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
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
g2/enervision#133
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
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?
Élévation du #40. Pas prioritaire au sens du jalon, mais payé par tout le monde à chaque demande de fusion.
Le constat, mesuré
La chaîne met 7 min 34 sur une demande (exécution #232, PR #125). Sept jobs, un seul exécuteur : ils ne s'exécutent pas en parallèle, ils font la queue.
Le coût n'est pas dans les contrôles, il est dans ce qu'on refait :
apt-get installpip install -r requirements-dev.txtnpm cisurservices/dashboardqualite,tests-unitairesetdependances-pythondéclarent le mêmecontainer:au même sha256, et refont chacun le même apt puis la même installation Python.dependances-dashboardettableau-de-bordinstallent tous deux les dépendances npm du même projet.Ce que je propose
pipet un cachenpm, clés portées parrequirements-dev.txt, lespyproject.tomlapplicatifs etpackage-lock.json.Sans risque pour la protection de branche : le contrôle obligatoire est
Intégration / *, un joker. Aucun nom de job n'y est figé, les renommer et les fusionner ne casse rien.Ce que je ne propose pas, et pourquoi
Un
paths-ignorepour les demandes de documentation. C'est la version dangereuse : le workflow ne se joue pas du tout, donc aucun contrôle ne rapporte son statut, et le jokerIntégration / *n'a rien à quoi se raccrocher. La demande peut rester bloquée en silence — le même mode de panne que la protection de branche du 1er septembre.Et l'idée suppose que la documentation soit vérifiée par « ce qui a du sens pour elle ». Aujourd'hui rien ne vérifie un
.md: ni les liens, ni le format. Filtrer par chemin ne rendrait pas la chaîne intelligente, cela la débrancherait pour une classe de fichiers.Donc, dans l'autre sens : donner à la documentation son propre contrôle avant de lui donner une voie rapide. Un cas d'essai vérifie que les liens relatifs des
.mdmènent à un fichier existant. Dix manuels se citent les uns les autres et un fichier renommé casse ces renvois en silence, jusqu'au jour où on en a besoin, c'est-à-dire en panne. Mesuré à l'écriture : 111 liens relatifs dans 62 fichiers.Reste ouvert, après celui-ci
La sortie anticipée par périmètre. Faisable sans danger, mais à l'intérieur des jobs et jamais par
paths-ignore: le job démarre, regarde si un fichier de son périmètre a changé, et sort vert en quelques secondes sinon. Il rapporte toujours son statut, donc aucun piège de protection. Demande d'abord d'éprouver sur une branche jetable ce que fait le joker face à un contrôle absent, ce qui ne se devine pas.Le contrôle des secrets ne devra jamais se sauter : un secret peut arriver dans un
.md.lenaic referenced this issue2026-09-04 09:36:53 +00:00