A project omnibus-gitlab-mirror was created to make use of multi-project pipelines for package-and-qa jobs. In this project, master branch was opened to all Developers of gitlab-org to merge (but explicitly disabled MRs from project settings so that no one actually does). Doing this enabled them to run pipeline against master branch, which meant we could use multi-project pipelines for triggering jobs instead of using a specific bot user's token.
This issue is to track implementing the same thing in gitlab-qa, using a mirror called gitlab-qa-mirror. It also makes sense to tackle #261 (closed) along with it.
@rymai@balasankarc - Is there a reason why this is linked to #261 (closed)? Can a gitlab-qa-mirror be created without transitioning the ownership of the runners for gitlab-qa and #261 (closed) be done afterwards?
I think the reason was to stop using the Distribution's runners, but I might miss something else.
If that is the reason, the next question would be: is that ok if we continue using the Distribution's runners for now so that we can tackle https://gitlab.com/gitlab-org/security/gitlab/issues/67 sooner rather than later, and then go back to set up our own (i.e. Quality) dedicated runners?
@kwiebers The existing runner is tied to this (gitlab-qa) project. So, if we are moving to a new project, it will essentially mean registering a new runner and associating it to the gitlab-qa-mirror job (and deprecating the existing runner). Me and Remy thought that was a perfect opportunity to move the runner also to QA ownership. Hence it was linked to #261 (closed).
That being said, I am perfectly fine with us decoupling this and continuing to use Distribution's runner, if that will unblock stuff.
@balasankarc Thanks for the answer! That wasn't clear to me after a few months. We should probably document that somewhere.
The existing runner is tied to this (gitlab-qa) project. So, if we are moving to a new project, it will essentially mean registering a new runner and associating it to the gitlab-qa-mirror job (and deprecating the existing runner).
I think we'd want to also keep this runner for gitlab-qa. Or maybe it's possible to attach a runner to multiple projects? Otherwise, two runners are fine too.
That being said, I am perfectly fine with us decoupling this and continuing to use Distribution's runner, if that will unblock stuff.
I think we'd want to also keep this runner for gitlab-qa. Or maybe it's possible to attach a runner to multiple projects? Otherwise, two runners are fine too.
I didn't see any straight forward way. Maybe via some Rails magic? We may want to ask Runner team. For omnibus-gitlab, we went with a separate runner.
Hmm, I do remember visiting that page while I investigated, but can not remember why I didn't go with that. It is very much possible I overlooked something and doing this is possible easily - if so, it is the simplest solution.