Improve developer experience for repositories mirrored in GitLab

Context:

• We wanted to improve the developer experience in several of the sysadmins team's GitLab projects (e.g. puppet-tails and gitlab-config). This meant allowing folks to:
  • set Assignee and Reviewer for MRs.
  • use our GitLab Runners for CI.
• We adjusted GitLab configuration and gave Developer permissions to different groups.

Problems (quoting @intrigeri):

• It happens that some of our repositories are hosted elsewhere using Gitolite and are then mirrored to GitLab.
• This totally breaks the branch/MR workflow for branches that only exist in the GitLab mirror:
  • Such branches are deleted when we push to Gitolite and @role-mirror-to-GitLab mirrors it to GitLab.
  • Good: yes, it's still possible to fetch and merge the branch manually, via the merge-requests/* ref.
  • Bad: no, the MR does not work (for any reasonably user-centric definition of "works"). More specifically:
    • @role-mirror-to-GitLab closes the MR.
    • Even after reopening the MR manually, it shows a MR with no change, which is mostly useless.
    • Pushing the branch again to Gitolite (so its mirrored back to GitLab) is not a good workflow: any subsequent change pushed to GitLab will be overwritten during the next mirror push.

Possible actions:

• Stop encouraging our colleagues to use this workflow. At least in the current state of our Puppet Git setup, we should instead encourage them to push to their own fork.
• Check whether it's feasible to authorize specific people to use our runners in their own fork's CI.