GitLabのユーザー名変更が実際に影響する範囲
GitLabのユーザー名変更は、プロフィールの編集ではなく、公開範囲に影響する名前空間の移行として扱ってください。プロフィールのハンドルとプロジェクトURLのパスは連動しているため、名前を変更すると古いパスを指すあらゆるものに影響する可能性があります。
GitLabのユーザー名を変更すると、アカウントの個人名前空間も変更されます。Source
この一点だけでも、確認は名前変更の後ではなく前に済ませるべき理由がわかります。プロジェクト、ページ、パッケージ、外部参照のいずれかが古い名前空間のパスに依存しているなら、事前にそれを把握し、どう対処するかを決めておく必要があります。
文書化されている2つの障害要因
GitLabはユーザー名変更について特定の前提条件を明示しています。範囲は狭いものの、ここで承認された情報源が示す唯一の障害要因の組み合わせなので、最初の関門として使ってください。
ユーザー名変更の前提条件は、名前空間にContainer Registryタグを持つプロジェクトがなく、GitLab Pagesをホストするプロジェクトもないことです。Source
実際には、個人名前空間内のプロジェクトを棚卸しし、Container Registryタグを使っているものやGitLab Pagesをホストしているものを特定する必要があります。これらは名前変更を進める前に解決するか移転する必要があるプロジェクトです。これらの機能を使っていないプロジェクトが自動的に安全だと決めつけないでください。情報源が示しているのは前提条件であり、起こりうる下流の影響の完全なリストではありません。
実行前にリダイレクトの挙動を確認する
承認された情報源によると、GitLabはユーザー名を変更する前にリポジトリのリダイレクトの挙動を確認するよう案内しており、新しいユーザー名のパスはプロフィールのアカウント設定にあり、「Update username」という操作で適用されます。
GitLabはユーザー名を変更する前にリポジトリのリダイレクトの挙動を確認するよう案内しており、プロフィールのアカウント設定に新しいユーザー名のパスと「Update username」があります。Source
リダイレクトの挙動は、名前変更が無害に見えても何かを壊しうるポイントです。何かを変更する前に、自分のアカウントに適用されるリダイレクトのガイダンスを読み、何をカバーし何をカバーしないのかを記録してください。自分のプロジェクトでリダイレクトがどう振る舞うか確認できない場合は、いったん止めて先にそれを解決してください。古いパスに何が依存しているかを確認するまで、名前変更を無害とみなすべきではありません。
依存関係ワークシート
見つけた内容を記録するためにこのワークシートを使ってください。変更を行う前に記入し、何を決めたかの記録として保管してください。
| 確認項目 | 記録する内容 | 停止条件 |
|---|---|---|
| 個人名前空間のプロジェクト | 名前空間内の各プロジェクトと、Container RegistryタグやGitLab Pagesを使っているかどうか | いずれかのプロジェクトがContainer Registryタグを持つ、またはGitLab Pagesをホストしている |
| リダイレクトの挙動 | リダイレクトのガイダンスが古いパスについて何を述べ、どのプロジェクト種別をカバーしているか | 自分のプロジェクトにリダイレクトがどう適用されるか確認できない |
| 公開参照 | 古い名前空間のパスを示しているページ、ドキュメント、README、プロフィール | 参照を更新もリダイレクトもできない |
| 所有権 | アカウントと名前変更対象のプロジェクトを自分が管理していること | 影響を受けるプロジェクトの所有権が不明確 |
| 下流の利用者 | 古いパスをクローン、リンク、依存している人 | その人たちに伝えられない、または動作する代替パスを提供できない |
このワークシートは出発点であり、保証ではありません。承認された情報源は起こりうる依存関係をすべて示しているわけではないので、自分の環境に固有のものがあれば行を追加してください。
手順ごとの確認
- 個人名前空間内のプロジェクトを一覧にする。それぞれについて、Container Registryタグを使っているか、GitLab Pagesをホストしているかを記録する。
- いずれかのプロジェクトにどちらかの依存関係がある場合、名前変更の前に削除するか移転するか、その他の方法で解決するかを決める。文書化された障害要因が残っている間は進めない。
- リポジトリのリダイレクトのガイダンスを読み、自分のプロジェクトについて何をカバーしているかを書き留める。答えが不明確なら停止する。
- 公開向けの資料から古い名前空間のパスを検索する。プロジェクトページ、README、ドキュメント、自分の作業にリンクしているプロフィールなど。
- アカウントと影響を受けるすべてのプロジェクトを自分が管理していることを確認する。所有権が不明確なら停止する。
- ワークシートが完成し、停止条件に該当しない場合にのみ、プロフィールのアカウント設定に進み、新しいユーザー名を入力して「Update username」を実行する。
- 変更後、記録した参照を再確認し、それぞれがまだ解決するか、更新済みであることを確認する。
想定しておくべき失敗の経路
- 障害要因のプロジェクトが残っている。 Container RegistryタグやGitLab Pagesを持つプロジェクトがまだ名前空間にある場合、文書化された前提条件の下では名前変更を進められません。回避しようとせず、先に解決してください。
- リダイレクトのカバー範囲が不明確。 リダイレクトの挙動を確認できない場合、名前変更は未検証として扱い、いったん止めてください。仮定のまま進めることが、この確認が防ごうとしている失敗の形です。
- 公開参照を見落とす。 古い名前空間のパスはドキュメント、README、プロフィールに残ることがあります。変更後に記録したリストをたどり、追従しなかったものを修正してください。
- 所有権が不確か。 プロジェクトやアカウントを自分が管理しているか確信が持てない場合は停止してください。所有権が明確でないまま行う名前変更は、ほどくのがより難しい問題を生みます。
この確認でわからないこと
承認された情報源は、名前空間を参照する可能性のある下流のシステムをすべて説明しているわけではなく、名前変更が無害であることを約束してもいません。また、プロフィールのアカウント設定のパスと「Update username」の操作以外のメニューの詳細も示していません。情報源が沈黙している箇所では、仮定で埋めずにワークシートにギャップとして記録してください。
関連する次のタスク
名前変更が済み、プロジェクトの参照が安定したら、別の問題として、あなたのユーザー名が他の場所で何を表に出しているかがあります。ハンドルが公開プラットフォームのどこに現れるかを見たい場合は、ユーザー名からソーシャルメディアアカウントを見つける方法のガイドがそのタスクを扱っています。2つの作業は分けておいてください。GitLabの確認は名前空間の依存関係についてであり、ユーザー名の検索は公開プロフィールについてです。公開された一致は手がかりであり、所有権の証明ではありません。