feat(server-nestjs): migrate repository sync route to API v2

[KepoParis]

Issues liées

Issues numéro: #2423

---

Suite de la pile « repository API v2 » (#2408) : dernière route restée sur le serveur legacy.

Quel est le comportement actuel ?

La synchronisation d'un dépôt (déclenchement du miroir GitLab) est uniquement servie par
l'API v1 (legacy). L'API v2 des repositories expose le CRUD mais pas le sync, et
server-nestjs ne sait pas déclencher de pipeline de mirroring.

Quel est le nouveau comportement ?

Ajout de POST /api/v2/projects/:projectId/repositories/:repositoryId/sync (204),
permission ManageRepositories, mêmes contraintes que les autres mutations
(@RequireProjectStatus, @RequireProjectLocked(false), @RequireUserType('human')).

Contrat / schémas (shared)

• SyncRepositorySchema : union discriminée sur syncAllBranches. Une synchro complète
  ne peut pas porter de branchName (la clé est retirée au parsing), une synchro
  partielle ne peut pas l'omettre (400).
• Route syncRepositoryV2 dans le contrat ts-rest v2.

Événement (events)

• Événement repository.sync avec RepositorySyncEventPayload et l'action de log admin
  Sync Repository.
• emitRepositoryEvent renvoie les PluginResults fusionnés : contrairement à
  project.upsert (non bloquant), l'appelant attend le résultat, car la synchro est
  l'intention même de la requête et son échec doit être visible dans la réponse.

GitLab

• GitlabClientService.triggerMirror : le pipeline de mirroring est porté par le dépôt
  mirror du projet et cible le dépôt via la variable PROJECT_NAME (+ SYNC_ALL et
  GIT_BRANCH_DEPLOY). Les dépôts de plomberie de la console (SPECIAL_REPO_NAMES :
  infra-apps, mirror) sont refusés comme cible.
• GitlabService.handleRepositorySync écoute repository.sync et remonte un
  RequiredPluginResult<'gitlab'>.

Service repository

• syncRepository vérifie que le dépôt appartient bien au projet du chemin (404
  sinon), attend les résultats des plugins et transforme un plugin en échec en 422.
• Parité legacy : la création d'un dépôt avec externalRepoUrl déclenche un premier
  miroir en fire-and-forget (l'échec est tracé dans le log admin, la création reste
  201).

Tests : couverture du schéma, du client GitLab, du service GitLab, du service et du
controller repository.

Cette PR introduit-elle un breaking change ?

Non. La route v1 reste inchangée et continue d'être servie par le serveur legacy ; la v2
est ajoutée en parallèle. Aucun changement côté client.

Autres informations

Avec cette PR, l'API v2 des repositories couvre l'intégralité des routes v1. Reste à
faire hors de cette PR : la bascule du client sur les routes v2.

[cloud-pi-native-sonarqube]

Quality Gate passed

Issues

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

Measures

• 0 Security Hotspots
• 2.70% Coverage (53.90% Estimated after merge)
• 0.00% Duplicated Code (4.10% Estimated after merge)

Project ID: cloud-pi-native_console_AYsa46O31ebDtzs-pYyZ

View in SonarQube

[StephaneTrebel]

Hmm ok oui le plan c'est de migrer la logique un peu telle quelle et on reverra après un fois débarassés de server.