The GitLab backend is written primarily with Rails so it uses Rails routing. Beside Rails best practices, there are few rules unique to the GitLab application. To support subgroups, GitLab project and group routes use the wildcard character to match project and group routes. For example, we might have a path such as:
However, paths can be ambiguous. Consider the following example:
It's ambiguous whether there is a subgroup named
edit or whether
this is a special endpoint to edit the
To eliminate the ambiguity and to make the backend easier to maintain,
we introduced the
/-/ scope. The purpose of it is to separate group or
project paths from the rest of the routes. Also it helps to reduce the
number of reserved names.
We have a number of global routes. For example:
Every group route must be under the
gitlab-org/-/edit gitlab-org/-/activity gitlab-org/-/security/dashboard gitlab-org/serverless/-/activity
To achieve that, use the
scope '-' method.
Every project route must be under the
/-/ scope, except cases where a Git
client or other software requires something different.
gitlab-org/gitlab/-/activity gitlab-org/gitlab/-/jobs/123 gitlab-org/gitlab/-/settings/repository gitlab-org/serverless/runtimes/-/settings/repository
Migrating unscoped routes
Currently, the majority of routes are placed under the
/-/ scope. However,
you can help us migrate the rest of them! To migrate routes:
- Modify existing routes by adding
- Add redirects for legacy routes by using
- Create a technical debt issue to remove deprecated routes in later releases.
To get started, see an example merge request.