feat(server-nestjs): expose repository API v2 routes

[KepoParis]

Issues liées

Issues numéro: #2423

---

PR 5/5 de la pile « repository API v2 ». Base : feat/repository-v2-service.

Quel est le comportement actuel ?

La gestion des repositories est uniquement exposée par l'API v1 (legacy).

Quel est le nouveau comportement ?

Exposition de l'API v2 des repositories dans server-nestjs, montée sous
/api/v2/projects/:projectId/repositories :

Route	Code	Permissions	Contraintes
GET /	200	ListProjects (admin) + ListRepositories (projet)	—
POST /	201	ManageRepositories	statut projet, projet non verrouillé, utilisateur human
PUT /:repositoryId	200	ManageRepositories	idem
DELETE /:repositoryId	204	ManageRepositories	idem

Détails :

• ProjectGuard sur le controller : le projectId du chemin est résolu en contexte
  projet, injecté par @Project(), l'utilisateur par @AuthUser().
• Contraintes portées par les seules mutations : @RequireProjectStatus('initializing', 'created', 'failed', 'warning'), @RequireProjectLocked(false) et
  @RequireUserType('human') (équivalent du !perms.user legacy). Le GET n'en porte
  aucune.
• Validation : corps parsés par ZodValidationPipe avec CreateRepositorySchema /
  UpdateRepositorySchema, et repositoryId validé par ParseUUIDPipe.
• Enregistrement de RepositoryModule dans main.module.ts.
• Couverture de tests du controller.

Cette PR introduit-elle un breaking change ?

Non. L'API v1 reste inchangée ; la v2 est ajoutée en parallèle.

Autres informations

Reste à faire dans une PR de suivi, hors de cette pile :

• route de synchronisation (sync), qui reste servie par le serveur legacy
• migration externalToken vers Vault
• gestion tri-state de l'update

[StephaneTrebel]

🚀

The base branch was changed.

[shikanime]

CI failure investigation — PR #2408

Two distinct failures were observed on this PR's CI runs. They have different root causes; only one is a code defect introduced by this PR.

1. Run 31160631139 / job 92810239818 — server-nestjs unhealthy (the real blocker)

Symptom from the job log:

Container dso-console_server-nestjs  Starting
Container dso-console_server-nestjs  Started
Container dso-console_server-nestjs  Waiting
Container dso-console_server-nestjs  Error
dependency failed to start: container dso-console_server-nestjs is unhealthy

The container exits ~1.6s after start (Started 08:16:20.177 → Error 08:16:21.755). That is a process crash at bootstrap, not a slow healthcheck — the Dockerfile start-period is 15s. init-env.sh runs docker compose up -d (detached), so the app's own stderr is not captured in this step. That is why the log shows only the compose error and not the actual NestJS exception.
Recommendation: surface the bootstrap error in CI — run docker compose up in the foreground, or docker logs dso-console_server-nestjs after the failure.

Root cause: this PR is the first always-loaded module to import VaultModule unconditionally.

apps/server-nestjs/src/modules/repository/repository.module.ts:

imports: [AppEventsModule, InfrastructureModule, VaultModule],   // VaultModule NOT gated

Every other consumer of VaultModule gates it behind USE_VAULT (project-secrets.module.ts, healthz.module.ts, plugin.module.ts all use ConditionalModule.registerWhen(VaultModule, 'USE_VAULT')). In CI, .env.docker sets USE_VAULT=false and defines no VAULT_URL/VAULT_TOKEN (see apps/server-nestjs/.env.docker-example).

apps/server-nestjs/src/config/vault.config.ts requires both at bootstrap:

const vaultFeatureSchema = z.object({
  VAULT_TOKEN: z.string().min(1),
  VAULT_URL: z.string().url(),
  ...
})
export const vaultConfigFactory = registerAs('vault', () => vaultFeatureSchema.parse(process.env))

VaultClientService injects vaultConfigFactory.KEY, so instantiating VaultModule → VaultClientService → vaultConfigFactory() throws a ZodError → NestJS bootstrap aborts → container exits → healthcheck fails. The repo's own test proves the throw: vault.config.spec.ts → "throws when a required var is missing".

This same server-nestjs healthcheck failure appeared on earlier PRs too (e.g. #2376 — tasks t_a6d4549f / t_213dc334), so there may be additional CI flakiness around this service. But the unconditional VaultModule import is a definite regression introduced here and must be fixed regardless.

Suggested fix (mirror the existing project-secrets pattern exactly):

1. repository.module.ts — gate the import:

   import { ConditionalModule } from '@nestjs/config'
   // ...
   imports: [AppEventsModule, InfrastructureModule, ConditionalModule.registerWhen(VaultModule, 'USE_VAULT')],

2. repository.service.ts — make the vault dependency optional and guard the writes, like ProjectSecretsService:

   @Inject(VaultClientService) @Optional() private readonly vault?: VaultClientService,

   and skip this.vault.writeGitlabMirrorCreds(...) / deleteGitlabMirrorCreds(...) when this.vault is undefined (warn + continue — the mirror-cred write is non-essential when Vault is not configured, same contract as project-secrets).

2. Run 31162821982 / job 92820073455 — invalid reference format (NOT a code defect)

This run used TAG: pr-#2408 (note the literal #):

Inputs
  TAG: pr-#2408
  PR_NUMBER: #2408
...
docker pull "${GHCR_CACHE}/cloud-pi-native/console/${img}:pr-#2408"
docker tag  "${GHCR_CACHE}/cloud-pi-native/console/${img}:pr-#2408" "dso-console/${img}:ci"
invalid reference format

Docker image tags cannot contain #, so the pull/tag fails before compose even starts. This was triggered via manual workflow_dispatch of workflow-merge-queue.yml with PR_NUMBER: #2408 (the # was included). workflow-merge-queue.yml builds TAG: pr-${{ github.event.inputs.PR_NUMBER ... }} → pr-#2408.

Note: the normal PR CI (workflow-continuous-integration.yml) uses TAG: pr-${{ github.event.number }} → pr-2408 (valid), which is why run A pulled correctly. So run B is an operator input mistake, not a repository bug. Human-side fix: enter the PR number without the # (2408), or strip it in the workflow (${github.event.inputs.PR_NUMBER#\#}).

Recommended next steps

1. Apply the USE_VAULT gating fix above — fixes the real CI blocker (run A).
2. Re-run the PR CI; if server-nestjs still fails its healthcheck, the docker logs from step 1 will now surface the next error.
3. Re-trigger run B with PR_NUMBER: 2408 (no #).

[KepoParis]

Thanks @shikanime for this very detailed CI investigation 🕵️‍♂️ 👌🏾

[cloud-pi-native-sonarqube]

Quality Gate passed

Issues

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

Measures

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

Project ID: cloud-pi-native_console_AYsa46O31ebDtzs-pYyZ

View in SonarQube