라우팅

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 설명 예시 수행할 작업
스크립트와 자동화에 사용 가능 snippet#raw 한 주요 릴리즈를 위해 이전 및 새로운 URL을 모두 지원합니다. 그런 다음, 다른 주요 릴리즈를 위해 이전 URL에서 새로운 URL로의 리다이렉트를 지원하세요.
저장되거나 공유될 가능성이 높음 issue#show 다음 주요 릴리즈까지 이전 URL에서 새로운 URL로의 리다이렉트를 추가하세요.
제한된 사용, 공유될 가능성이 적음 admin#labels 추가 단계가 필요하지 않습니다.

모든 경우에, 이전 경로는 트래픽이 충분히 감소한 후에만 제거해야 합니다 (예: 로그 또는 BigQuery에 따라). 그렇지 않으면, 사용자가 제거 전에 이를 알릴 노력을 더 해야 할 수 있습니다.

스코프가 없는 경로 마이그레이션

현재 대부분의 경로는 /-/ 범위 아래에 위치하고 있습니다. 그러나 나머지를 마이그레이션하도록 도와주세요! 경로를 마이그레이션하려면:

  1. 기존 경로를 수정하여 - 범위를 추가합니다.
  2. Gitlab::Routing.redirect_legacy_paths를 사용하여 레거시 경로에 대한 리다이렉트를 추가합니다.
  3. 나중의 릴리즈에서 더 이상 사용되지 않는 경로를 제거하기 위한 기술 부채 이슈를 생성합니다.

시작하려면 예시 머지 요청을 참조하세요.

유용한 링크