You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
🐛 [BUG] - Réconciliation SonarQube non idempotente : les variables CI GitLab échouent en 'already been taken' #2616
Depuis le portage du provisioning des variables CI GitLab dans server-nestjs (issue #2538, corrigée), la synchronisation d'un projet n'est pas idempotente : une seconde synchronisation échoue avec 400 Bad Request sur la création des variables de dépôt.
Le provisioning passe par SonarqubeService.ensureGitlabCiVariables, qui appelle GitlabClientService.setGitlabRepoVariable (apps/server-nestjs/src/modules/gitlab/gitlab-client.service.ts). Cette méthode vérifie l'existence de la variable via ProjectVariables.show avec un filtre environment_scope ; quand la variable existe déjà (clé + scope), la vérification peut ne pas la matcher selon la version de GitLab / la gestion des scopes, et le chemin de création est alors emprunté. La création POST /projects/:id/variables échoue car GitLab impose l'unicité (key, environment_scope) : la variable existe déjà → {"key": ["(PROJECT_NAME) has already been taken"]}.
L'erreur remonte et fait échouer la totalité de la réconciliation (ensureGitlabCiVariables → ensureProjectRepositories → ensureProjectGroup → syncProject), que ce soit via l'événement project.upsert ou le cron.
À l'inverse, tous les autres créateurs de ce fichier (createGroup, createSubGroup, createUser, getOrCreateRepo) tolèrent l'erreur "has already been taken" en rechargeant la ressource existante. setGitlabRepoVariable et setGitlabGroupVariable sont les seuls sans cette tolérance.
Etapes de reproduction
Activer le plugin SonarQube (USE_SONARQUBE=true) sur un projet existant avec au moins un dépôt.
Déclencher une première synchronisation (création / mise à jour) : les variables PROJECT_KEY, PROJECT_NAME, SONAR_PROJECT_PROPERTIES, SONAR_TOKEN sont provisionnées.
Déclencher une seconde synchronisation du même projet.
Constater l'échec : GitbeakerRequestError400 sur POST /api/v4/projects/<id>/variables, (PROJECT_NAME) has already been taken.
Captures d'écran
Logs
{"name":"GitbeakerRequestError","message":"Bad Request","status":400,
"url":"http://gitlab-webservice-default.dso-gitlab.svc.cluster.local:8181//api/v4/projects/575/variables",
"method":"POST","description":{"key":["(PROJECT_NAME) has already been taken"]}}
Navigateurs
OS
Version de la console impactée
server-nestjs (réécriture en cours).
Définition du fini
setGitlabRepoVariable et setGitlabGroupVariable tolèrent l'erreur "has already been taken" et reprennent sur la variable existante (idempotence de la réconciliation).
Un test de non-régression couvre une seconde synchronisation (ou un create rejeté par GitLab) et vérifie que la réconciliation ne lève pas.
Issues liees
Relie a #2087 : migration des plugins vers une approche declarative (moteur Alchemy.run), dont cette idempotence est un prerequis.
Activity