라우팅

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. 나중의 릴리스에서 폐기된 경로를 제거하기 위해 기술 부채 이슈를 작성합니다.

시작하려면 예시 마지 제청을 참조하십시오.

유용한 링크