specific (locked) runner does not run merge requests
I'm not entirely sure if this is a bug or a feature, but it's neither well documented nor obvious.
A friend of mine has a private repo, with running CI. He uses a specific runner and locked that runner to his repo. I can see the code but not edit it, so if i'd like him to include some change, i fork the repo and then create a merge request. So all pretty standard.
Now my assumption was that as in github + travis that GitLab CI would automatically run the merge request (there's no restriction via only in the .gitlab_ci.yml). However, all i see is that CI is pending. Due to the fact that he locked the runner, i can't even enable it for my fork.
- Why is is this different?
- How is the interplay of shared, specific (locked) runners wrt. merge-request build triggering?
- If the runner wasn't locked, why not auto-activate it in my fork?
Documentation ~CI
Activity
Hi @joernhees. There is a small note about project specific runners not being shared with forked projects automatically in the runners documentation
yupp, that's in there, but nothing about the consequences... if not building merge requests is one of them, it would be quite good to mention this explicitly in a prominent position (maybe a tabular comparison of shared vs specific vs locked specific runners)?
Anyhow, my main point here is to ask if this is really the intended behavior, as it's a big usability blooper. It's THE feature that lowers the hurdle for contributors (their contribution is tested without the need for them to set up an own testing environment). If this is on purpose i'm interested in the rationale why specific runners can't just run the merge request. As the merge request is in the issue tracker of the upstream repo not of the contributor's repo, is it weird to expect the upstream runner to pick it up?
This is related to https://gitlab.com/gitlab-org/gitlab-ce/issues/23902. I'm closing this issue as it only describes a part of the problem.
