Repository navigation
Conversation
|
🤖 Hey ! A preview of the application is available at : https://console-pr-2775.dso.cpin-hp.numerique-interieur.fr Please be patient, deployment may take a few minutes. |
StephaneTrebel
left a comment
There was a problem hiding this comment.
La migration introduit quatre écarts bloquants de sécurité et de parité fonctionnelle. Ils doivent être corrigés avant la bascule Nginx de la MR empilée #2776.
shikanime
left a comment
There was a problem hiding this comment.
Verdict : Commentaire
Le monitor migré reproduit fidèlement la sémantique legacy (sonde périodique, dernier état servi entre passes, cause masquée sur la route publique, états SonarQube et sonde Harbor complète repris). Les points bloquants soulevés sur les commits précédents semblent traités à head ; seul un fragilité mineure subsiste dans le mapping du probe terminus.
b1888a6 to
8b0c087
Compare
43fbc77 to
a0fbda4
Compare
StephaneTrebel
left a comment
There was a problem hiding this comment.
La migration service-monitor remplace le registre legacy par des sondes Nest conditionnelles et conserve les trois niveaux d’accès ainsi que le format de réponse. Le ledger #1889 est global et non clos à l’échelle de cette PR ; fils résolus et CI verte sur cette tête.
shikanime
left a comment
There was a problem hiding this comment.
Revue du head 37a6405e — module service-monitor propre et bien cadré : le service agrège les health services terminus des modules plugins sans dépendre des paquets @cpn-console/*-plugin ni du registre hooks (les 7 dépendances plugin sont bien retirées de package.json, et plus aucun import résiduel sur le head), gating ConditionalModule.registerWhen sur USE_* avec Keycloak toujours actif, routes admin gardées (ListSystem / ManageSystem) en parité avec le legacy. fromHealthCheck(result, key) reçoit bien la clé d'indicator explicitement — pas de devinette sur la forme de unknown, narrow par type-guard, zéro cast as. 25 specs ajoutées, aucune supprimée. Les specs d'adaptation (registry-health monitor() sur /api/v2.0/health, sonarqube SONARQUBE_HEALTH_STATUS) reproduisent le comportement legacy documenté. Rien de bloquant.
Résumé des sévérités : 0 bloquant, 0 important, 2 nits.
Deduplicate the private isRecord copies in service-monitor.utils and sonarqube-health.service onto src/utils/record.utils, next to hasEntries. Co-authored-by: Automata <automata@shikanime.studio> Signed-off-by: William Phetsinorath <william.phetsinorath-open@interieur.gouv.fr> Change-Id: I86a0cc083756a99f4b7f47c8c7ce8a596a6a6964 Signed-off-by: Shikanime Deva <22115108+shikanime@users.noreply.github.com>
6d8d6f7 to
aa67145
Compare
StephaneTrebel
left a comment
There was a problem hiding this comment.
✨ La migration reprend les trois routes, les permissions différenciées et les verdicts Harbor/SonarQube plutôt que de se limiter à un simple ping. Aucun finding relevé dans le diff ; la bascule nginx reste explicitement portée par la MR empilée #2776.
… type block Co-authored-by: Automata <automata@shikanime.studio> Signed-off-by: William Phetsinorath <william.phetsinorath-open@interieur.gouv.fr> Change-Id: I6b3e511e25e17db048f94a7cb31bdbb56a6a6964
cf237df to
d124668
Compare
…ession Remove the parallel monitor() probe paths: Harbor and SonarQube expose a single check() that probes the legacy monitor endpoint and reports the verdict directly with indicator.up()/down(), carrying message and cause as indicator data. fromHealthCheck lifts message and cause into the MonitorInfos shape, so every probe aggregates through the same check() path without MonitorStatus leaking into the health services. Co-authored-by: Automata <automata@shikanime.studio> Signed-off-by: William Phetsinorath <william.phetsinorath-open@interieur.gouv.fr> Change-Id: I746a21c6837dd2c448f192aec7d763ca6a6a6964
d124668 to
8c355a5
Compare
Replace the private MonitoredService.lastStatus array and snapshot() with the module cache (CacheModule.register + @Inject(CACHE_MANAGER)), matching the registry and keycloak-secret-provider pattern. Reads fall back to the pending status until the first probe pass writes a key. Co-authored-by: Automata <automata@shikanime.studio>
Replace the hand-rolled setInterval timer (and its OnModuleDestroy cleanup) with @Cron(CronExpression.EVERY_5_MINUTES) on runAll, matching INTERVAL_MS; ScheduleModule.forRoot() is already global. onModuleInit keeps the first pass. Co-authored-by: Automata <automata@shikanime.studio>
The service now returns MonitorInfos.cause on every read; the public GET /health-services strips it in the controller, where the admin-only boundary lives. getCompleteServiceHealth and read(withCause) collapse into getServiceHealth; a cached status no longer merges over the pending fallback, so an OK entry never inherits the pending cause. Co-authored-by: Automata <automata@shikanime.studio>
The service returns the raw cached cause; toCause stringification now happens in toServiceHealth at the presentation layer, alongside the public-route stripping. fromHealthCheck stays in utils (probe parsing). Co-authored-by: Automata <automata@shikanime.studio>
toPublicServiceHealth replaces the inline destructure in health-services, keeping the admin-only cause rationale next to its siblings. Co-authored-by: Automata <automata@shikanime.studio>
Co-authored-by: Automata <automata@shikanime.studio>
|
🤖 Hey ! A preview of the application is available at : https://console-pr-2775.dso.cpin-hp.numerique-interieur.fr Please be patient, deployment may take a few minutes. |
Co-authored-by: Automata <automata@shikanime.studio> Signed-off-by: William Phetsinorath <william.phetsinorath-open@interieur.gouv.fr> Change-Id: If0057ad2b52eb20390f9f7649e26eb4c6a6a6964
The probe base64-encoded the token into a Bearer header — a Basic-auth payload under the Bearer scheme, which SonarQube rejects with 401, so the monitor reported UNKNOW on every pass. Send the raw token, matching sonarqube-http-client.service.ts. Co-authored-by: Automata <automata@shikanime.studio> Signed-off-by: William Phetsinorath <william.phetsinorath-open@interieur.gouv.fr> Change-Id: I3eb3aa5b70626b11321b2c40339b58916a6a6964
StephaneTrebel
left a comment
There was a problem hiding this comment.
La migration porte les trois routes, leurs permissions, les sondes conditionnelles et les verdicts Harbor/SonarQube, sans réintroduire les dépendances plugins retirées. Les checks de lint, tests, build, sécurité et Sonar sont verts sur cette tête ; le ledger global #1889 reste naturellement ouvert hors du périmètre de cette PR. Les deux threads nit existants (constante de message dupliquée et ordre d’import type) restent à traiter ou à clore explicitement, sans bloquer cette approbation.
Co-authored-by: Automata <automata@shikanime.studio> Signed-off-by: William Phetsinorath <william.phetsinorath-open@interieur.gouv.fr> Change-Id: Icd0efdbd5cd254d3f6a0bf09a700527a6a6a6964
Co-authored-by: Automata <automata@shikanime.studio> Signed-off-by: William Phetsinorath <william.phetsinorath-open@interieur.gouv.fr> Change-Id: I22dfe4768465ef30ee92028dcb71a23a6a6a6964
Move CACHE_KEY to constants, MonitoredService and pendingStatus to utils, rename runAll to refreshStatuses, add a readStatus private method, validate the probe detail with a zod schema, and share REQUEST_ERROR_MESSAGE from service-monitor instead of redefining it in the sonarqube plugin. Co-authored-by: Automata <automata@shikanime.studio> Signed-off-by: William Phetsinorath <william.phetsinorath-open@interieur.gouv.fr> Change-Id: Ibdc5ba2cb37552b8b3ef7030c2b4bccd6a6a6964
|
StephaneTrebel
left a comment
There was a problem hiding this comment.
La migration et ses tests sont présentes ; les contrôles CI sont verts et les anciens fils de revue sont résolus. Le ledger #2720 reste incomplet : la documentation demandée n’est pas livrée, et le fonctionnement en mode dev n’est pas établi par les éléments vérifiés ; ledger 2/4. Preuve du critère documentaire restant :
- [ ] La documentation liée a été ajoutée

2 New Issues
0 Fixed Issues
0 Accepted Issues
Issues liées
Refs #1889
Quel est le comportement actuel ?
Les routes
GET /api/v1/health-services,GET /api/v1/complete-servicesetGET /api/v1/refresh-servicessont servies par l'ancienne application Fastifyapps/server, via le registreservicesde@cpn-console/hooks.Quel est le nouveau comportement ?
Migration du module
service-monitorversapps/server-nestjs:ServiceMonitorController: routesGET /health-services,GET /complete-services(adminListSystem),GET /refresh-services(adminManageSystem).ServiceMonitorService: agrège les services de santé terminus de chaque module plugin (ArgoCDHealthService,GitlabHealthService,RegistryHealthService,KeycloakHealthService,NexusHealthService,SonarqubeHealthService,VaultHealthService). Aucune dépendance aux paquets@cpn-console/*-pluginni au registreservicesde@cpn-console/hooks, tous deux appelés à être supprimés.PluginModuleetHealthzModule:ConditionalModule.registerWhensur les variablesUSE_*, Keycloak toujours actif ; les sondes sont exécutées à l'initialisation du module.MonitorInfosetMonitorStatusde@cpn-console/shared(plus de type local dupliqué), narrow typé sansasconformément à la politique stricte du dépôt, titres legacy des plugins (ArgoCD,Gitlab,Harbor,Keycloak,Nexus,SonarQube,Vault), etcauserenseigné sur les sondes en échec comme dans la registry legacy.Cette PR introduit-elle un breaking change ?
Non.
Autres informations
Parité avec l'ancien serveur : mêmes routes, même schéma de réponse (
MonitorInfos), mêmes permissions admin. Le nom affiché est le titre du plugin (ex.ArgoCD), comme avec le registre hooks.