### Problem to solve Project's configuration is done through settings managed with the UI or API. Ideally we should be able to have all those settings available as object defined within the git repository. That will enforce settings being passed when cloning a repository, when using a template, etc... ### Intended users * [Delaney (Development Team Lead)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#delaney-development-team-lead) will use that feature as it will help him ensure all of the projects under his control are set up properly : - protected master branch - slack/jira integration - merge request approval settings - ... ### Further details You can see https://gitlab.com/gitlab-org/gitlab/issues/13961 , https://gitlab.com/gitlab-org/gitlab/issues/26580 , https://gitlab.com/gitlab-org/gitlab/issues/16119 , https://gitlab.com/gitlab-org/gitlab/issues/34370 are trying to solve similar issue by setting group level permission, but those could be inherited from a fork and changed on first import easily, ie : without using the ui or api. ### Proposal The proposal is to leverage a .gitlab folder (but not firm on the exact folder name as long as it exists) with yaml based configuration to enforce some or all settings available through the api. ### Permissions and Security CODEOWNERS will be leveraged to make sure changing those settings are done with review. Of course we get the benefit of tracking the full history of the project in term of setting, we have the git support for tracking history now that settings are managed as file. ### Documentation Adding the matching snippet in the various api docuemntation would help a lot for adoption. ### Availability & Testing We don't have that feature yet, but I built something using the same flow. I have a file to configure all the projects in my group: ``` --- jira: url: https://jira.acme.org service: active: True commit_events: True merge_requests_events: True slack: channel: platform-engineering service: active: True notify_only_broken_pipelines: True push_events: False issues_events: False confidential_issues_events: False merge_requests_events: True tag_push_events: True pipeline_events: True wiki_page_events: False enforce: printing_merge_requests_link_enabled: True approvals_before_merge: 2 only_allow_merge_if_all_discussions_are_resolved: True reset_approvals_on_push: True merge_requests_require_code_owner_approval: True merge_requests_author_approval: False disable_overriding_approvers_per_merge_request: False ``` I have a project at the top level of the org that read that file and environment variable, to enforce recursively the settings of all the projects in the group I'm running against. ie ``` script: - enforce -g 6929 -f config.yaml ``` It's a first step but it makes it difficult to have a project to differ slightly from the rest, and of course the settings are applied to a new project only after the first run. I envision something matching the various pages in the UI .gitlab/integration/jira.yml .gitlab/integration/slack.yml .gitlab/general/merge-request.yml [...] ### What does success look like, and how can we measure that? We could close probably a few of open issues, with that approach. In my perspective I would deactivate that project enforcer at the group level, and push my settings in my various project (or import from like in gitlab-ci) ### What is the type of buyer? I'd say it could be a competitive advantage for project management in gitlab as a whole, so would offer it on the free tier ### Links / references