Allow CI Reports to be Namespaced to support monorepos
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Release notes
Problem to solve
In a monorepo, there is a need to segment aspects of scans and test reports based on parts of the repository (whether that is a specific file or application) rather than inherently all of the contents of the repository. In GitLab, reports are currently tied to artifacts and the artifacts are tied to the gitlab-ci.yaml file which is tied to the project, so this means that reports are viewed at the whole entirety of the project or source code repo.
As GitLab is leveraged for more diverse source code and CI needs, we are missing the ability to scope CI Report Artifacts within specific areas of a repository.
Currently all results for a given "report type" (i.e. sast or junit or many others) get merged into the same dataset. This is convenient when I want MANY jobs to funnel into a single report, but for when I want to have different Reports for different areas within a given codebase, I am unable to do so.
For DAST, oftentimes the "Default Branch" will be used to deploy to multiple environments and if multiple environments run DAST scans, the results will be a combination of all environments - which is not helpful.
Intended users
User experience goal
We ought to support namespaces for Artifact Reports
Proposal
Add a namespace designation so that reports when defined can be namespaced.
sast:app1:
variables:
CI_PROJECT_DIR: app1/
artifacts:
reports:
sast: gl-sast-report.json
namespace: app1
sast:app2:
variables:
CI_PROJECT_DIR: app2/
artifacts:
reports:
sast: gl-sast-report.json
namespace: app2OR like how environment namespaces work:
sast:app1:
variables:
CI_PROJECT_DIR: app1/
artifacts:
reports:
sast/app1: gl-sast-report.json
sast:app2:
variables:
CI_PROJECT_DIR: app2/
artifacts:
reports:
sast/app2: gl-sast-report.jsonOR - leverage CODEOWNERS Sections (thanks @dzalbo) for the idea.
Augmented by "labelling' vulnerability objects with section names from CODEOWNERS. A lot of customers using monorepos already employ CODEOWNERS as a solution to set up ownership and approval rules based on which component was modified. We could apply the same logic and automatically categorize vulnerabilities (at least SAST and SCA as they can be tracked to specific location within repository). This way there will be no need to set up namespaces in CI and the solution would also work well with incremental SAST scanning (Incremental SAST scanning (only scan code chang... (#419734))
Further details
This is vital for to enable support for monorepo architectures.