fix(server-nestjs): use project owner email for sonarqube user creation

[shikanime]

Issues liées

Issues numéro: #2400

---

Quel est le comportement actuel ?

Quel est le nouveau comportement ?

Cette PR introduit-elle un breaking change ?

Autres informations

[StephaneTrebel]

SonarQube: use project.owner.email for user creation instead of
synthetic {slug}@{slug}

GitLab: revoke old mirror tokens on rotation, validate tokens via
API call, restore 1-year token expiry, set ciConfigPath and user
creation hardening (canCreateGroup, forceRandomPassword, projectsLimit)

Vault: group restructure and techRO path divergence are intentional
with built-in roles

E2E: realigned tests with DSO orchestration docs, fix gating

Donc déjà au moins quatre commits atomiques 😅 (en fait j'en compte bien, bien plus)

Et n'hésite pas à découper en MRs stackées, je sens que je vais souvent les revoir, ces 419 lignes. Profitons d'avoir un peu de marge pour améliorer notre process de revue 🙂

[shikanime]

Review — PR #2403 (reviewer)

Scope actually reviewed: 9 files, +123/-83, all in sonarqube/ + apps/server-nestjs/src/modules/vault/vault-client.service.ts. Verified locally: vitest run on sonarqube + vault specs → 37/37 pass; diff is internally type-consistent (no dangling callers of the old Promise<…Response> shape). CI green on latest commit.

blocker

• PR body ≠ diff. The description ("Remove DB_URL gate from 5 e2e specs, standardize describe.runIf, add handleDelete assertions to vault/keycloak/gitlab/nexus/registry, fix gitlab/keycloak handleDelete, add zone.e2e-spec.ts") does not match the pushed diff at all. The real change is: SonarQube search APIs become paginating async generators, user creation uses project.owner.email instead of synthetic {slug}@{slug}, SONAR_PASSWORD is optional in the vault secret, and readTechnReadOnlyCreds is typed VaultSecret<MirrorUserSecret>. Please rewrite the description to reflect the actual diff (or rebase onto the intended commits). As-is it will mislead future readers and the changelog.

warning

• @StartActiveSpan() on async generators is a no-op for tracing. sonarqube-client.service.ts:273 (searchUsers) and :301 (searchProject) are decorated, but StartActiveSpan only awaits then-able returns (telemetry.decorator.ts:50). An AsyncGenerator is not promise-like, so the span is ended on the first return and the body inside the generator runs outside any span. Not harmful, just dead instrumentation. Either drop the decorator from these two methods or make StartActiveSpan wrap generators. (Established sibling async generators in keycloak/gitlab are not decorated, so this is inconsistent with the codebase.)

nit

• ensureUser log at sonarqube.service.ts:331 prints email=${project.owner.email} — fine, but if owner is ever absent this throws before the log. Not reachable today (every project has a non-null owner, loaded via projectSelect in project-queries.utils.ts:218), so no action needed; just noting the invariant the new required owner field on ProjectWithDetails now depends on.

Things checked and clean

• project.owner.email is safe: projectSelect includes owner, and the plugin dispatcher reloads the project (emitProjectEvent → getProject) before calling handleUpsert.
• All 6 callers of searchUsers/searchProject updated to the async-generator contract (service, e2e spec, client spec). No stragglers.
• vault-client.service.ts SonarqubeUserSecret.SONAR_PASSWORD? + MirrorUserSecret/VaultSecret<T> generic: type-safe, gitlab consumer (gitlab.service.ts:496-502) matches.
• getAll helper reused from utils/iterable.utils.ts rather than reinvented.

Verdict: REQUEST CHANGES — only for the blocker (description mismatch). The code itself is mergeable; fix the description and this is good to go.

[cloud-pi-native-sonarqube]

Quality Gate passed

Issues

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

Measures

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

Project ID: cloud-pi-native_console_AYsa46O31ebDtzs-pYyZ

View in SonarQube