Segregate access control regarding running pipelines from ability to push/merge.
Context in gitlab-qa#63 (closed)
Three places where we can possibly use multi-project pipelines, but are unable to because of current implementation's limitations:
- Triggering a package, docker image and QA build from CE and EE repositories, for developers to test their changes in CE/EE codebase.
- Triggering a package, docker image and QA build from omnibus-gitlab repositories, for developers to test their changes in omnibus-gitlab codebase.
- Triggering CNG docker image builds used for review apps from CE and EE repositories.
In all these scenarios, the pipelines triggered will be against master branch of omnibus-gitlab or CNG projects, which will fail because most of the developers don't have access to run pipelines against master branch there. Because these projects are of much importance and are the final gates between what reaches the users/customers, we can not open up master branch for everyone to push/merge to master branch or create tags. They need to be controlled tightly.
The workaround we are using right now is triggering these pipelines using one bot user that is made owner on all projects. This is definitely not ideal, either from a usability stand point or from a security one.
What we need is a way to let all our developers to just run pipelines against master branch, without the ability to push/merge to it. In a clearer way "access control segregation between ability to push/merge and ability to run pipelines".
Having this, along with gitlab-ce#39640 will let Distribution and QA teams use multi-project pipelines. Without both of this, multi-project pipelines are essentially unusable for us.
@marin : Please confirm if what I stated above is correct and needed for us to use MPP internally.
/cc @@grzesiek @rymai @meks @bikebilly