fix(server-nestjs): make GitLab CI variable provisioning idempotent - #2617
Open
shikanime wants to merge 3 commits into
Open
fix(server-nestjs): make GitLab CI variable provisioning idempotent#2617shikanime wants to merge 3 commits into
shikanime wants to merge 3 commits into
Conversation
shikanime
force-pushed
the
fix/gitlab-ci-variable-idempotent
branch
2 times, most recently
from
August 28, 2026 14:20
135e1d3 to
78b70fc
Compare
shikanime
added a commit
that referenced
this pull request
Aug 28, 2026
PR #2617's idempotent variable commit (78b70fc) deleted three unrelated test blocks — auditor flag tests, pipeline trigger token tests, and group Members tests — that exist on the base branch. This commit restores them while keeping the legitimate idempotent variable tests added by the PR. Signed-off-by: William Phetsinorath <william.phetsinorath-open@interieur.gouv.fr> Change-Id: I2b7cffab1ad665f7f441c61f13a37f446a6a6964
shikanime
marked this pull request as ready for review
August 28, 2026 15:01
Signed-off-by: William Phetsinorath <william.phetsinorath-open@interieur.gouv.fr> Change-Id: If066b86e9ee93fb1f33c9eb2a44eac076a6a6964
PR #2617's idempotent variable commit (78b70fc) deleted three unrelated test blocks — auditor flag tests, pipeline trigger token tests, and group Members tests — that exist on the base branch. This commit restores them while keeping the legitimate idempotent variable tests added by the PR. Signed-off-by: William Phetsinorath <william.phetsinorath-open@interieur.gouv.fr> Change-Id: I2b7cffab1ad665f7f441c61f13a37f446a6a6964
…e guards Addresses SonarQube S3604-style warnings on the ensure* variable writers and restores the EOF newline stripped from the touched files. Co-authored-by: Automata <automata@shikanime.studio> Signed-off-by: William Phetsinorath <william.phetsinorath-open@interieur.gouv.fr> Change-Id: I1ac1fb1bae0b821d9c0265bad089253e6a6a6964
shikanime
force-pushed
the
fix/gitlab-ci-variable-idempotent
branch
from
August 28, 2026 15:54
0e29fbf to
f332a9f
Compare
|
0 New Issues
0 Fixed Issues
0 Accepted Issues
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issues liées
#2616
Quel est le comportement actuel ?
Depuis le portage du provisioning des variables CI GitLab dans
server-nestjs(issue #2538), la réconciliation d'un projet n'est pas idempotente.setGitlabRepoVariableetsetGitlabGroupVariablecréent une variable quand leurshowscopé ne la trouve pas ; mais une réconciliation concurrente ou antérieure peut l'avoir créée entre-temps. GitLab impose l'unicité(key, environment_scope), donc la création échoue avec400 "has already been taken"et propage l'erreur à toute la synchronisation SonarQube (ensureGitlabCiVariables → ensureProjectRepositories → ensureProjectGroup), que ce soit via l'événementproject.upsertou le cron.Quel est le nouveau comportement ?
La collision de création est tolérée comme pour tous les autres
getOrCreate*du fichier (createGroup,createSubGroup,createUser,getOrCreateRepo) : sur"has already been taken", la variable existante est rechargée puis réconciliée (no-op si identique, édition sinon) au lieu de faire échouer la synchronisation. Une seconde réconciliation devient un no-op.Cette PR introduit-elle un breaking change ?
Non.
Autres informations
project.upsertne lève pas (idempotence de la réconciliation).