feat(deployment): persist and validate deployment value sources

[KepoParis]

Issues liées

Issues numéro: #2247

---

Note

PR empilée (stacked) sur #2369. À rebaser sur main une fois #2369 mergée.

Quel est le comportement actuel ?

Les sources de valeurs (internes / externes) ne sont pas encore exploitées par l'API : impossible de les créer, mettre à jour ou valider sur une source de déploiement.

Quel est le nouveau comportement ?

Modélisation stricte (parse, don't validate)

• Une source de valeurs est soit interne, soit externe : deux relations dédiées DeploymentInternalValueSource / DeploymentExternalValueSource, et côté schémas partagés une union discriminée par type (internal | external).
• Ajout de types nommés exportés (CreateDeploymentValueSource, UpdateDeploymentValueSource, CreateDeploymentSource, UpdateDeploymentSource, DeploymentValueSource, DeploymentSource) dont CreateDeployment / UpdateDeployment / Deployment se servent, plutôt que des accès indexés (X['deploymentSources'][number]...).

API — écriture (create / update)

• Exposition d'une liste ordonnée valueSources (discriminée par type) sur les sources de déploiement. La position dans la liste est conservée (order), préservant l'entrelacement internal / external.
• Contraintes : au plus une source externe par source de déploiement (superRefine + contrainte d'unicité en base) ; une source externe doit référencer un dépôt (repositoryId) et un ref.

API — lecture (read)

• La lecture renvoie les value sources sous la forme d'une seule liste ordonnée valueSources (discriminée par type, avec id et order), symétrique de la forme d'écriture. La fusion des deux relations persistées est faite une fois, côté serveur (serializeDeployment, triée par order) : les consommateurs (client, CLI…) n'ont plus à reconstruire la liste. Les deux tables restent un détail de stockage non exposé par l'API.

Parsing au niveau du boundary serveur

• parseCreateDeployment / parseUpdateDeployment convertissent le payload validé en un modèle précis avant toute écriture : l'externe devient un champ optionnel unique (et non une liste), et les entrées sont séparées en création / mise à jour (buckets …ToCreate / …ToUpdate).

Persistance

• Création via nested create ; mise à jour via create / update / deleteMany pour les sources internes, et upsert / delete pour l'unique source externe (relation to-one).
• getDeploymentById utilise findUniqueOrThrow (un id inconnu est une erreur, pas un null qui se balade). Le datastore charge internalValueSources (triées par order) + externalValueSource ; le service les fusionne en valueSources via serializeDeployment avant de répondre.

Tests

• Tests unitaires de deployment.utils.ts : partitionnement, préservation de l'ordre, séparation create/update, branches d'upsert/delete de la source externe, et fusion ordonnée de la lecture (serializeDeployment).

Cette PR introduit-elle un breaking change ?

Non. Les valueSources sont optionnelles (default([])) ; les déploiements existants restent valides.

Autres informations

Partie API de l'adaptation au nouveau helm-chart (https://github.com/cloud-pi-native/helm-charts) permettant d'ajouter des valeurs externes au chart dso-env. Les composants client suivront dans une PR distincte (#2374) et consommeront la liste valueSources ainsi que les types nommés exposés ici.

Remonté en cours de revue et traité séparément : #2383 (filtre d'exception global Prisma P2025 → 404).

[github-actions]

🤖 Hey !

The security scan report for the current pull request is available here.

[github-actions]

🤖 Hey !

The security scan report for the current pull request is available here.

[StephaneTrebel]

On n'est pas loin, mais n'hésite pas à être beaucoup plus intransigeant sur le typage. On ne s'autorise aucun "trou dans la raquette" qui pourrait revenir nous mordre par la suite.

J'ai eu la même conversation avec @shikanime hier à ce sujet. undefined, null, etc. c'est terminé. On serre tous les boulons qu'on peut serrer, le plus tôt possible !

Parse, don't validate

[github-actions]

🤖 Hey !

The security scan report for the current pull request is available here.

[github-actions]

🤖 Hey !

The security scan report for the current pull request is available here.

The merge-base changed after approval.

[cloud-pi-native-sonarqube]

Quality Gate passed

Issues

• 0 New Issues
• 5 Fixed Issues
• 0 Accepted Issues

Measures

• 0 Security Hotspots
• 14.30% Coverage (26.20% Estimated after merge)
• 0.00% Duplicated Code (4.20% Estimated after merge)

Project ID: cloud-pi-native_console_AYsa46O31ebDtzs-pYyZ

View in SonarQube