ルーティング

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#raw1つのメジャーリリースについて、古いURLと新しいURLの両方をサポートします。その後、別のメジャーリリースのために古いURLから新しいURLへのリダイレクトをサポートします。
保存または共有される可能性が高いものissue#show次のメジャーリリースまで、古いURLから新しいURLへのリダイレクトを追加します。
限定的な使用、共有される可能性は低いadmin#labels余分なステップは不要

スコープされていないルートのマイグレーション

現在、大半のルートは/-/ スコープの下に置かれています。しかし、残りのマイグレーションを手伝うことができます!ルートをマイグレーションするには

  1. - スコープを追加して、既存のルートを修正してください。
  2. Gitlab::Routing.redirect_legacy_paths を使って、レガシールートのリダイレクトを追加します。
  3. 後のリリースで非推奨のルートを削除するために技術的負債のイシューを作成してください。

まずはマージリクエストの例をご覧ください。