## Description A `.gitlab-ci.yml` may contain rules to deploy application to production server and (ususally) runs automaticaly after push. It's not always wanted that any developer could change this. ## Proposal By implementing https://gitlab.com/gitlab-org/gitlab/issues/14376, we make it so that the `.gitlab-ci.yml` can be pointed to in a different repo. In this way, the configuration can reference a file in another project with a completely different set of permissions. The file should be publicly accessible, but can be editable only by users in the other project. This issue then becomes a documentation issue, describing how to solve this problem using the solution provided in https://gitlab.com/gitlab-org/gitlab/issues/14376. ### Original Proposal Originally we discussed using the [code owners](https://docs.gitlab.com/ee/user/project/code_owners.html) feature, by using the "Require code owner approval" toggle available in gitlab-ce~2278657. The idea was that as long as the `CODEOWNERS` file itself is locked down with a code owner and the `Require code owner approval` is checked then this is can already be accomplished. We realized, though, that `CODEOWNERS` is not sufficient as-is today to solve this problem because users can still push changes to `.gitlab-ci.yml` and have pipelines for merge request to run with the changed `.gitlab-ci.yml`. What would needed is to block changes from reaching the remote branch or at least to drop a pipeline immediately if unauthorized changes are made to a `.gitlab-ci.yml`. Given this, the new proposal is simpler and as effective in achieving the same thing.