Follow-ups to setup router project
Things not yet done from https://handbook.gitlab.com/handbook/engineering/gitlab-repositories/#creating-a-new-project
For https://gitlab.com/gitlab-org/cells/router:
-
Add the project to the list of GitLab projects in projects.yml. -
Help AppSec categorizing your new project. -
Add a CODEOWNERS file, to make it easy for contributors to figure out which teams are best suited to review their changes. Use teams rather than individuals as owners, to make it self updating over time and resilient to people taking time off You can scope ownership to subdirectories or individual files, but it should contain at the very least a top-level catch all for any new or non explicitly mentionned file. -
When possible, projects should have the following Merge request settings enabled: -
Merge Trains. -
Delete source branch after merge. -
Merge only if pipeline succeeds. -
Merge only when all threads are resolved.
-
-
Projects should have the minimum Baseline Configurations setup for MR Approval Rules and Protected Branch Settings -
Projects should have Users can request access setting disabled to discourage granting accidental external access. -
If needed, make sure to set up a default CI/CD configuration. -
If your project contains code that is distributed with GitLab or is executed in production, set up security jobs for your project and add your project to the AppSec team’s triage rotation. The AppSec will triage security findings from the Security Dashboard and create issues for vulnerabilities. -
If the project is part of work that is shipped to customers, add it to projects_part_of_product.csv by opening an MR to that file or following the process outlined by Engineering Productivity. => https://gitlab.com/gitlab-data/analytics/-/merge_requests/9964 -
If the repository is public, set up a security mirror. This is necessary to address security vulnerabilities without disclosing them before they are fixed.
Edited by Bojan Marjanovic