ルーティング
GitLabのバックエンドは主にRailsで書かれているので、Railsルーティングを使います。Railsのベストプラクティス以外に、GitLabアプリケーション独自のルールがいくつかあります。サブグループをサポートするために、GitLab のプロジェクトルートとグループルートではワイルドカード文字を使います。たとえば、次のようなパスがあるとします:
/gitlab-com/customer-success/north-america/west/customerA
しかし、パスはあいまいなこともあります。次の例を考えてみましょう:
/gitlab-com/edit
edit
という名前のサブグループがあるのか、gitlab-com
グループを編集するための特別なエンドポイントなのかが曖昧です。
曖昧さをなくし、バックエンドのメンテナーを簡単にするために、/-/
スコープを導入しました。このスコープの目的はグループもしくはプロジェクトのパスを残りのルートから分離することです。また、予約名の数を減らすのにも役立ちます。
利用可能なすべてのルートを見る
コンソールから次のコマンドを実行すると、ルートを表示したり検索したりできます:
rails routes | grep crm
また、ブラウザでhttp://gdk.test:3000/rails/info/routes
にアクセスしてルートを表示することもできます。
グローバルルート
グローバルルートはいくつもあります。例えば
/-/health
/-/metrics
グループルート
すべてのグループルートは/-/
スコープの下になければなりません。
例:
gitlab-org/-/edit
gitlab-org/-/activity
gitlab-org/-/security/dashboard
gitlab-org/serverless/-/activity
そのためには、scope '-'
メソッドを使います。
プロジェクトルート
Gitクライアントや他のソフトウェアが異なるものを要求する場合を除き、すべてのプロジェクトルートは/-/
。
例:
gitlab-org/gitlab/-/activity
gitlab-org/gitlab/-/jobs/123
gitlab-org/gitlab/-/settings/repository
gitlab-org/serverless/runtimes/-/settings/repository
既存路線の変更
必要でない限り、既存のページのURLを変更しないでください。どうしても変更しなければならない場合は、ユーザーに気づかれないようにしてください。404 Not Found
、避けられるのであれば、受け取ってほしくないからです。この表を参考にしてください:
URLの説明 | 物件例 | To-Do |
---|---|---|
スクリプトやオートメーションで使用可能 | snippet#raw | 1つのメジャーリリースについて、古いURLと新しいURLの両方をサポートします。その後、別のメジャーリリースのために古いURLから新しいURLへのリダイレクトをサポートします。 |
保存または共有される可能性が高いもの | issue#show | 次のメジャーリリースまで、古いURLから新しいURLへのリダイレクトを追加します。 |
限定的な使用、共有される可能性は低い | admin#labels | 余分なステップは不要 |
スコープされていないルートのマイグレーション
現在、大半のルートは/-/
スコープの下に置かれています。しかし、残りのマイグレーションを手伝うことができます!ルートをマイグレーションするには
-
-
スコープを追加して、既存のルートを修正してください。 -
Gitlab::Routing.redirect_legacy_paths
を使って、レガシールートのリダイレクトを追加します。 - 後のリリースで非推奨のルートを削除するために技術的負債のイシューを作成してください。
まずはマージリクエストの例をご覧ください。