Earlier quoted context omitted.
Let me see if I understand it. Let's say I whitelist user "me" and user "foo" using this variable in the .gitlab-ci.yml. Let's also assume I have runners locked to my repo. Doing nothing else than that, user foo now submits a merge request from their fork to my repo. Does CI now run for that merge request?
If it is a forked project, CI should run in their own project I believe. It should not run on your Runners.
So consider the following common pattern:
1. Someone (new employee, FLOSS volunteer, doesn't matter) forks my repo. That's the normal way of working in Gitlab.
2. Someone creates a feature branch, tests it, considers it ready for merging. Again, common flow.
3. Someone creates a merge request. Totally reasonable.
So far so good. Now let's keep going.
4. I notice the merge request. It has almost certainly timed out and failed because new users don't come to the job with their own set of runners.
5. The only sane option is for me to allow them to use my runners. Ok, let's do it-- I must do the following:
6. Either have them add me to their fork with sufficient permissions to set up the runners, or log in to Gitlab as root, impersonate them, and add myself.
7. Unlock my runners from my repo and manually enable each one in the new user's fork using the Gitlab UI.
8. Retry the CI.
9. When it passes, either a) lock the runners again or b) put up with runners getting used by every single commit by the new user (which nobody, including the new user, wants).
Now, I could probably set up the runners as an initial step in welcoming a new user into the fold. That would save me the failure step #4 above. And maybe I could set up a webhook and an additional webserver to listen for it so that I can only trigger on merge requests.
But that's back to the old svn permissions pattern plus custom server hacks. That is what I wanted to avoid in the first place by using Git.
I really do want to use either a single variable or a single button click to mean "go ahead and use my runners for this particular user's merge requests." Or even, "go ahead and use my runners for this particular merge request." Even that would be a vast UX improvement.
The only serious alternative right now is for me to create a "dev" branch, have new users make merge requests to it, and just make a habit of accept them there to trigger CI. Then if tests pass merge them into master.
But that requires yet more documentation for new users and more complexity in the flow.