라우팅
GitLab v19.2요약
GitLab 백엔드는 주로 Rails로 작성되어 있으므로 Rails 라우팅을 사용합니다. 그러나 경로는 모호할 수 있습니다. edit이라는 이름의 하위 그룹이 있는 것인지, 아니면 gitlab-com 그룹을 편집하기 위한 특수 엔드포인트인지 모호합니다.
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
조직 라우트#
조직 스코프 라우트는 /o/:organization_path/*path 패턴을 사용합니다. 이러한 라우트는 config/routes.rb에서 조직 스코프 내의 모든 기존 라우트를 재정의함으로써 생성됩니다.
예시:
/o/my-org/projects
/o/my-org/groups
/o/my-org/-/settings
모든 라우트는 config/routes.rb의 스코프 블록을 사용하여 /o/:organization_path 접두사 아래에 재정의됩니다. 예를 들어, /o/my-org/projects는 조직 컨텍스트를 요청 전반에 걸쳐 보존하면서 /projects와 동일한 컨트롤러로 라우팅됩니다.
이 방식은 별도의 컨트롤러나 라우트 정의 없이 모든 라우트의 조직 스코프 버전을 생성합니다.
Devise OmniAuth 콜백(동적 세그먼트 아래에 스코프를 지정할 수 없음)과 API 라우트를 포함한 일부 라우트는 아직 조직 스코프로 지정되지 않았습니다.
조직 라우팅 구현에 대한 자세한 내용은 조직 개발 문서를 참조하세요.
기존 라우트 변경#
필요한 경우가 아니면 기존 페이지의 URL을 변경하지 마세요. 변경이 필요한 경우,
사용자가 눈치채지 못하도록 변경하세요. 가능하다면 사용자가 404 Not Found를
받지 않도록 해야 합니다. 다음 표에서 각 상황에 필요한 최소 조치를 설명합니다:
| URL 설명 | 예시 | 처리 방법 |
|---|---|---|
| 스크립트 및 자동화에 사용될 수 있음 | snippet#raw | 한 주요 릴리즈 동안 이전 URL과 새 URL을 모두 지원합니다. 그런 다음 다음 주요 릴리즈 동안 이전 URL에서 새 URL로의 리다이렉트를 지원합니다. |
| 저장되거나 공유될 가능성이 있음 | issue#show | 다음 주요 릴리즈까지 이전 URL에서 새 URL로의 리다이렉트를 추가합니다. |
| 사용 빈도가 낮고 공유될 가능성이 없음 | admin#labels | 추가 단계가 필요하지 않습니다. |
모든 경우에서, 이전 라우트로의 트래픽이 충분히 감소한 경우에만(예: 로그 또는 BigQuery에 따라) 해당 라우트를 제거해야 합니다. 그렇지 않으면, 제거를 다시 고려하기 전에 사용자에게 더 많은 노력을 기울여 사용 중단에 대해 알려야 할 수 있습니다.
스코프가 지정되지 않은 라우트 마이그레이션#
현재 대부분의 라우트는 /-/ 스코프 아래에 있습니다. 그러나
나머지 라우트를 마이그레이션하는 데 도움을 줄 수 있습니다! 라우트를 마이그레이션하려면:
-
-스코프를 추가하여 기존 라우트를 수정합니다. -
Gitlab::Routing.redirect_legacy_paths를 사용하여 레거시 라우트에 리다이렉트를 추가합니다. -
이후 릴리즈에서 더 이상 사용되지 않는 라우트를 제거하기 위한 기술적 부채 이슈를 생성합니다.
시작하려면 머지 리퀘스트 예시를 참조하세요.
JavaScript 경로 헬퍼 업데이트#
모든 Rails 라우트에는 프론트엔드에서 URL을 더 쉽게 생성할 수 있도록 해주는 JavaScript 경로 헬퍼 대응 항목이 있습니다. Rails 라우트를 업데이트할 때는 JavaScript 경로 헬퍼를 다시 생성해야 합니다. Lefthook 검사와 CI 검사가 이들이 Rails 라우트와 동기화된 상태를 유지하도록 보장합니다. JavaScript 경로 헬퍼를 다시 생성하려면 bin/rake gitlab:js:routes를 실행하고 변경 사항을 커밋하세요.