Ce qu’un changement de nom d’utilisateur GitLab modifie réellement
Traitez un changement de nom d’utilisateur GitLab comme une migration de namespace aux conséquences publiques, pas comme une modification de profil. Le pseudonyme de votre profil et le chemin de vos URL de projet sont liés : un renommage peut donc affecter tout ce qui pointe vers l’ancien chemin.
Changer de nom d’utilisateur GitLab modifie aussi le namespace personnel du compte. Source
Ce seul fait explique pourquoi la vérification doit avoir lieu avant le renommage, et non après. Si un projet, une page, un paquet ou une référence externe dépend de l’ancien chemin de namespace, vous devez le savoir à l’avance et décider comment il sera traité.
Les deux blocages documentés
GitLab énonce un prérequis précis pour un changement de nom d’utilisateur. Il est étroit, mais c’est le seul ensemble de blocages établi par la source approuvée ici : utilisez-le comme premier filtre.
Un prérequis au changement de nom d’utilisateur est que le namespace ne contienne aucun projet avec des tags Container Registry ni aucun projet hébergeant GitLab Pages. Source
Concrètement, vous devez inventorier les projets de votre namespace personnel et identifier ceux qui utilisent des tags Container Registry ou hébergent GitLab Pages. Ce sont les projets à résoudre ou à déplacer avant que le renommage puisse avoir lieu. Ne supposez pas qu’un projet sans ces fonctionnalités est automatiquement sûr : la source établit ces éléments comme prérequis, pas comme une liste exhaustive de tous les effets en aval possibles.
Vérifiez le comportement des redirections avant de valider
La source approuvée indique aussi que GitLab invite les utilisateurs à vérifier le comportement des redirections de dépôt avant de changer de nom d’utilisateur, et que le chemin du nouveau nom d’utilisateur se trouve dans les paramètres de compte du profil, avec une action Update username.
GitLab invite les utilisateurs à vérifier le comportement des redirections de dépôt avant de changer de nom d’utilisateur ; les paramètres de compte du profil proposent le chemin du nouveau nom d’utilisateur et Update username. Source
C’est sur le comportement des redirections qu’un renommage peut sembler inoffensif tout en cassant quelque chose. Avant de modifier quoi que ce soit, lisez les consignes de redirection qui s’appliquent à votre compte et notez ce qu’elles couvrent et ne couvrent pas. Si vous ne pouvez pas vérifier comment les redirections se comportent pour vos projets, arrêtez-vous et résolvez ce point d’abord. Un renommage ne doit pas être considéré comme inoffensif tant que vous n’avez pas vérifié ce qui dépend de l’ancien chemin.
Fiche de dépendances
Utilisez cette fiche pour consigner ce que vous trouvez. Remplissez-la avant d’effectuer le changement et conservez-la comme trace de vos décisions.
| Vérification | À consigner | Arrêtez-vous si |
|---|---|---|
| Projets du namespace personnel | Chaque projet du namespace et s’il utilise des tags Container Registry ou GitLab Pages | Un projet a des tags Container Registry ou héberge GitLab Pages |
| Comportement des redirections | Ce que les consignes de redirection disent des anciens chemins et quels types de projets elles couvrent | Vous ne pouvez pas confirmer comment les redirections s’appliquent à vos projets |
| Références publiques | Pages, documentation, README ou profils qui affichent l’ancien chemin de namespace | Une référence ne peut pas être mise à jour ou redirigée |
| Propriété | Que vous contrôlez le compte et les projets renommés | La propriété d’un projet affecté est incertaine |
| Utilisateurs en aval | Toute personne qui clone, lie ou dépend de l’ancien chemin | Vous ne pouvez pas les prévenir ou fournir un chemin de remplacement fonctionnel |
Cette fiche est un point de départ, pas une garantie. La source approuvée n’établit pas toutes les dépendances possibles : ajoutez des lignes pour tout ce qui est spécifique à votre configuration.
Vérification étape par étape
- Listez les projets de votre namespace personnel. Pour chacun, notez s’il utilise des tags Container Registry ou héberge GitLab Pages.
- Si un projet présente l’une de ces dépendances, décidez s’il faut la supprimer, la déplacer ou la résoudre autrement avant le renommage. Ne poursuivez pas tant qu’un blocage documenté subsiste.
- Lisez les consignes de redirection de dépôt et notez ce qu’elles couvrent pour vos projets. Si la réponse est floue, arrêtez-vous.
- Recherchez l’ancien chemin de namespace dans vos supports publics : pages de projet, README, documentation et profils qui renvoient à votre travail.
- Confirmez que vous contrôlez le compte et chaque projet affecté. Si la propriété est incertaine, arrêtez-vous.
- Une fois la fiche remplie et aucune condition d’arrêt applicable, allez dans les paramètres de compte du profil, saisissez le nouveau nom d’utilisateur et utilisez Update username.
- Après le changement, revérifiez les références consignées et confirmez que chacune résout toujours ou a été mise à jour.
Chemins d’échec à anticiper
- Un projet bloquant subsiste. Si un projet avec des tags Container Registry ou GitLab Pages est encore dans le namespace, le renommage ne peut pas avoir lieu selon le prérequis documenté. Résolvez-le d’abord plutôt que de chercher un contournement.
- La couverture des redirections est floue. Si vous ne pouvez pas confirmer le comportement des redirections, considérez le renommage comme non vérifié et mettez-le en pause. Procéder sur une supposition est précisément le mode d’échec que cette vérification vise à prévenir.
- Une référence publique est oubliée. Les anciens chemins de namespace peuvent subsister dans la documentation, les README ou les profils. Parcourez votre liste consignée après le changement et corrigez ce qui n’a pas suivi.
- La propriété est incertaine. Si vous n’êtes pas sûr de contrôler un projet ou le compte, arrêtez-vous. Un renommage effectué sans propriété claire crée un problème plus difficile à défaire.
Ce que cette vérification ne vous dit pas
La source approuvée ne décrit pas tous les systèmes en aval susceptibles de référencer votre namespace, et elle ne promet pas qu’un renommage est inoffensif. Elle n’établit pas non plus de détails de menu au-delà du chemin des paramètres de compte du profil et de l’action Update username. Là où la source est muette, consignez la lacune dans votre fiche plutôt que de la combler par une supposition.
Une tâche connexe ensuite
Une fois le renommage effectué et vos références de projet stables, une question distincte se pose : ce que votre nom d’utilisateur expose désormais ailleurs. Si vous voulez voir où un pseudonyme apparaît sur les plateformes publiques, le guide sur comment trouver des comptes de réseaux sociaux par nom d’utilisateur couvre cette tâche. Gardez les deux travaux séparés : la vérification GitLab porte sur les dépendances de namespace, tandis qu’une recherche de nom d’utilisateur porte sur les profils publics, et une correspondance publique est une piste, non une preuve de propriété.