Project labels and selectors

Status: Closed because Compliance Framework Labels will be used as described in this issue.

Proposal

In GitLab Projects are managed in Groups. This setup lets users organize their projects in a hierarchy, where permissions are set locally or inherited from the upper level:

graph TD
    I[Instance] -->  G[Groups]
    G -->  P[Projects]

This also shapes how we are producing new features at GitLab, following exactly the same pattern: Following our Iteration core value, we first develop features at the project level, than Group level, and eventually at the Instance level:

graph LR
    P[Projects] --> G[Groups]
    G -->  I[Instance]

It means features can be applied for all sub-projects and sub-groups of a Group when a feature reaches this maturity level.
While this might work well for individuals and SMBs, it's not scaling well for large organizations. Defining behaviours and rules at the Group level makes the adoption of some features impossible when the number and variety of projects is increasing. Similary, defining rules that would apply to all projects under a certain group only works if the nature of the sub-projects is consistent, which is less and less likely with many projects.

To solve this, projects needs to be cherry picked based on their nature and properties. What applies to production/product projects won't necessary for demos or POCs. Moreover, reporting features become useless if metrics are biased with this kind of projects.

To make an analogy, the current way features are designed at GitLab is like applying the same rules and behaviours to all pods under the same namespaces. Network policies can't work that way, and fetching metrics doesn't make any sense if the traffic of all pods is gathered together. To solve this, Kubernetes introduced since the early days labels and selectors, which "enable users to map their own organizational structures onto system objects in a loosely coupled fashion". In other words, once metadata is applied to a pod, some rules and behaviours are automatically applied if they are selected.

This simple yet powerful way of selecting projects open new horizons, where the classic hierarchy detailed above is broken in something different:

graph TD
    I[Instance] -->  N[Namespace]
    N --> C[Categories]
    C --> P[Projects]

Instead of applying strictly features to all sub-projects, selectors can be used to have a fine grained configuration.

Examples

Vulnerability Reports and Security Dashboards

The Gitlab main repository is hosted directly under https://gitlab.com/gitlab-org, from the Project level to the Group level, there's just one step, but using the dashboards for https://gitlab.com/gitlab-org will then include a lot of sub projects.
Instead, we should have several Security Dashboards for the selections we need: One global for Security, one per team, maybe one per stage, ...

SBOM

The only way to build an SBOM correctly is to select the projects to be included in it. gitlab-org has thousands of projects, and not all of them need to be included in our SBOM. Only the projects part of the product must be considered.

In the same vein, storing all the dependencies in the DB won't be useful if we can't filter out the relevant projects.

Labels vs Topics

GitLab topics offer the right per-requisites to categorize projects, but should be evaluated carefully because of these drawbacks:

  • They have the same visibility as their project, so they are public for public projects.
  • Only Maintainers can update them.
  • Maintainers can update them without any review, which means if one project loses its "product" label for example, it could fall of our radar without being noticed.

They could not be a good fit for security purposes. This is why we manage a different set of categories in the inventory (internal link)

Implementation

Every feature designed to work at the Group level should be able to work with selectors too.

Edited by Philippe Lafoucrière