Skip to content

doc: documenter l'archivage fiable d'un projet #128

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
shikanime wants to merge 1 commit into
base: main
Choose a base branch
from
Open

doc: documenter l'archivage fiable d'un projet #128

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 12 additions & 0 deletions docs/administration/projets.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -18,3 +18,15 @@ En cliquant sur le projet concerné, une autre page s'ouvre sur laquelle les inf
- La configuration des plugins pour ce projet en particulier

![projet détail](/img/console_admin/projet_detail.png)

## Archivage d'un projet

La suppression d'un projet déclenche d'abord le nettoyage de l'ensemble de ses ressources externes (dépôts, environnements...), puis son archivage en base.

Le projet est verrouillé avant le nettoyage : toute modification est refusée pendant l'opération.

- Si le nettoyage échoue sur un service, le projet passe au statut « échoué » et l'API renvoie une erreur 422. Les nettoyages étant idempotents, la suppression peut être rejouée telle quelle.

@StephaneTrebel StephaneTrebel Oct 21, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟠 important (documentation): Ne pas garantir l’idempotence de tous les nettoyages

Le verrouillage permet de relancer la demande, mais ne rend pas automatiquement idempotente chaque suppression dans les services externes. La nouvelle justification est trop forte :

+- Si le nettoyage échoue sur un service, le projet passe au statut « échoué » et l'API renvoie une erreur 422. Les nettoyages étant idempotents, la suppression peut être rejouée telle quelle.

À la référence Console 17e109e2, le chemin project.delete → SonarqubeService.handleDelete → deleteProjectGroup appelle encore client.deleteProject sans tolérance du 404 ; le client HTTP propage toute réponse >= 400. Si deux nettoyages ont listé le même projet SonarQube, celui qui le supprime en second peut donc encore échouer parce qu’il est déjà absent. Ce comportement est précisément suivi dans Console #2785, toujours ouverte, y compris pour le site d’appel project.delete.

Sources : suppression de groupe projet SonarQube, client de suppression et propagation des erreurs HTTP.

Conserver l’explication du statut et de la possibilité de reprise, mais retirer la garantie générale : préciser qu’une partie des ressources peut déjà avoir été supprimée et qu’il faut examiner/corriger l’erreur du service en échec avant de relancer, sans promettre qu’un rejeu identique suffira. Le correctif backend reste hors périmètre de cette MR documentaire.

- Si le projet est modifié pendant le nettoyage, l'API renvoie une erreur 409 et l'archivage est refusé ; rejouez la demande.
- En cas de succès, les ressources externes sont supprimées, le slug est suffixé et le projet passe au statut « archivé ».

Un projet « échoué » reste verrouillé : un administrateur peut le déverrouiller puis relancer la suppression.
Loading