Hi,
We have a gitlab in a company cloud. They offer a shared runner but in our project, we don’t want to use it.
So, I defined a specific runner well configured for our project. But when my colleague want to use it in their frok, they don’t have the visibility on it.
How can we do to share a runner in a group ? (we tried group runner but the visibility is restricted to a group and the forks are not in the group)
I’m in the exact same situation. Previously we were using gitlab 8.x and what you described worked fine. A colleague forked the main project, committed to a working branch, pushed to his fork, and sent a MR to mainline. The specific runner registered on the mainline repo. tested his MR and all was well.
Recently our gitlab instance was upgraded to 10.x along with the runners. Everything works fine for owner MRs to mainline, but MR’s from my colleague’s fork try to utilize his runners (he doesn’t have any). After about 20min, his pipelines timeout.
He tried clobbering his fork, and re-forking, with a new MR. Same deal, it keeps trying to use his (non-existent runners) and failing. This seems like a critical design flaw and behavior change. A contributor should not need to setup runners to test a change on somebody else’s (or a group) repo.
Anyone else having this problem and/or found any workaround?
Hi cevich,
If you have a specific runner defined in your project, you can make all contributors maintainer of this project, they will have visibility on the runner everywhere, even in their fork.
But they will be maintainer, that’s mean a lot of right on the project, too much for us, that’s why we didn’t choose this solution.
You can also define a shared runner, but as I said, I don’t know how to reduce visibility to only a group.
We tried to define a group runner in the group that have the project but contributors don’t have visibility of the runner in their fork because their fork are in a different group that the project.
We guess that, if every members of the group were maintainer, maybe they will see the group runner in their fork but no.
And we don’t want every one as maintainer, it’s too much dangerous.
Finally, we found a way that is not perfect but acceptable.
We create a group which contain only one project (empty or not, we personally put gitlab runner configuration), you put every contributor maintainer of this project and we have set a specific runner on this project. And voilà, all maintainer of this project have now the visibility of the runner in their fork. This could be good for us but, in all this process, we have a manual action which is very annoying… We have to add/remove in the group depends on who want to contribute…
So, we are waiting for a better way to do it…
(Also, it’s not considering as a Bug or Feature proposal according to Gitlab, whereas it’s totally one, https://gitlab.com/gitlab-org/gitlab-ce/issues/46895)
Thanks for the feedback. Yes, I am facing those same challenge with those workarounds. Only workaround I found was to manually copy MR and push copy under my (maintainer) user.
This is a regression vs. previous behavior (it worked fine in 8.x).
It seems like a design-error, attempting to protect secret env. vars and runner access with over-general access control. Anyone with access to .gitlab-ci.yml can compromise runner and secret env. vars. Maybe this is why they make it maintainer-only.
A better solution would be to have an ‘approve’ button on MRs that a maintainer can press (after reviewing changes) to trigger specific runners. Since this could be a “feature”, maybe I should propose that as a “fix” since !46895 “not a bug”?
This problem seems to be an echo of Cross-project permissions for CI tokens (#18994) · Issues · GitLab.org / GitLab FOSS · GitLab
I read through most of that, but never saw any solution proposed/implemented for forks 
Update: After reading around in the docs, I think there might actually be a bug. Check out this section:
As a user:
* Make sure you are a member of the group or project you’re trying to have
access to. As an Administrator, you can verify that by impersonating the user
and retry the failing job in order to verify that everything is correct.
Clearly that’s the thing that seems to be broken. Though I haven’t tried putting my project into a group, @nchal said he tried this. We are using version ‘10.8.4 [update asap]’, odd they’d name a release that 
. I speculated at first, but perhaps this bug is fixed by an update. I did look through the changelog since 2268d0c but didn’t notice anything related (or missed it). Maybe it’s worth a second look.
We are using the latest gitlab version, and we have the same trouble. I don’t think that’s a bug but a design flaw