라우팅
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에 따라). 그렇지 않으면 해당 경로가 다시 제거될 수 있을 때까지 사용자들에게 폐기에 대해 알릴 추가적인 노력이 필요할 수 있습니다.
스코프가 지정되지 않은 경로 이주
현재 대부분의 경로가 /-/
스코프 아래에 있습니다. 그러나 나머지 경로도 마이그레이션하는 데에 도움이 될 수 있습니다! 경로 이주를 위해:
- 기존 경로를 수정하여
-
스코프를 추가합니다. -
Gitlab::Routing.redirect_legacy_paths
를 사용하여 레거시 경로에 대한 리디렉션을 추가합니다. - 나중의 릴리스에서 폐기된 경로를 제거하기 위해 기술 부채 이슈를 작성합니다.
시작하려면 예시 마지 제청을 참조하십시오.