Repository navigation
Conversation
|
🤖 Hey ! A preview of the application is available at : https://console-pr-2869.dso.cpin-hp.numerique-interieur.fr Please be patient, deployment may take a few minutes. |
|
🤖 Hey ! A preview of the application is available at : https://console-pr-2869.dso.cpin-hp.numerique-interieur.fr Please be patient, deployment may take a few minutes. |
There was a problem hiding this comment.
La mutualisation des identifiants miroir et de l’état projet est pertinente, mais le lookup double-encode les chemins de groupes et le saut de Projects.edit ne rétablit plus les noms nécessaires au miroir. La CI courante échoue aussi sur isGitbeakerNotFound absent du résultat intégré ; la dernière analyse Sonar annonce « 2 New Issues » malgré son gate vert (#2869 (comment)), donc le critère de zéro nouvelle issue n’est pas démontré. Aucun ticket de livraison lié : sans ledger, avec #2691 conservée comme contexte de rotation.
75225e6 to
6d44c6c
Compare
Le modèle de PR n'a aucun emplacement pour la preuve d'exécution : un recensement de 94 PR humaines fusionnées (organisations shikanime) montre que 54 % ajoutent à la main des preuves de vérification sans créneau dédié. Les PR console #2884 et #2869 illustrent ce contournement ; les organisations sœurs shikanime ont déjà adopté cette section exacte (shikanime-labs/.github, PR #11). Co-authored-by: Automata <automata@shikanime.studio>
6d44c6c to
b0eba78
Compare
c08fe53 to
cb9935e
Compare
|
Reprise sur le head actuel (cb9935e) : les trois points bloquants sont corrigés et vérifiés sur ce tree, les preuves détaillées sont dans les réponses de chaque thread.
Sur le critère SonarQube « zéro nouvelle issue » : le scan que vous citiez portait sur l'ancien head. Le cycle du head actuel affiche Quality Gate passed, 0 New Issues : #2869 (comment) Sur le ticket de livraison : #2949 porte le problème et le ledger (Définition du fini), lié dans le body du PR, avec #2691 conservée comme contexte de rotation. La carte Socle est passée à « To review ».
|
0b567ef to
0bea239
Compare
Signed-off-by: William Phetsinorath <william.phetsinorath-open@interieur.gouv.fr> Change-Id: Ie088e3acac9b27f37c29ba84e622385a6a6a6964
0bea239 to
ee789e8
Compare
|

0 New Issues
0 Fixed Issues
0 Accepted Issues
Pourquoi
Une synchronisation projet re-dérivait l'état à portée projet pour chaque dépôt : chemin de groupe re-résolu via l'endpoint de recherche paginé
Groups.all, attributs de groupe racine re-écrits à chaque résolution, identifiants de miroir tournés par dépôt (révoquant le jeton du dépôt précédent à chaque fois), et unProjects.editenvoyé même sans changement. Sur un projet de 80 dépôts, une sonde instrumentée mesure ~1480 appels GitLab par synchro, entièrement séquentiels — cohérent avec les réconciliations de 20 minutes rapportées (54 s auparavant sur 50 dépôts).Quoi
Groups.show(lookup O(1) par chemin) au lieu de la recherche paginéeProjects.editignoré quand topics, description etci_config_pathsont inchangésoffsetPaginatepasse par défaut à 100 par pageSonde instrumentée (client gitbeaker compté) : 56 → 40 appels pour un projet à 1 dépôt, 18 → 4 par dépôt supplémentaire, rotation de jeton 1/dépôt → 1/projet ; un projet de 80 dépôts passe de ~1480 à ~356 appels.
À fumer sur cpin-hp (label preview) : vérifier la durée d'une synchro complète sur le gros projet.
Références