We are an open source project:
And we have merge trains enabled. When new contributors come to send MRs, the pipeline however does not run, e.g.,: Fix build with mingw-w64 on Windows (!1290) · Merge requests · lfortran / lfortran · GitLab
How can this be fixed? This will soon become a very serious issue, since we are trying to grow and get a lot of contributors.
If we maintain our own runners on our own hardware, will those be able to run automatically somehow?
I have put the user as a developer of the project. The pipeline tab is now created, but the pipeline does not run. There is an
error tag and it says “The pipeline failed due to the user not being verified”:
Pipeline · lfortran / lfortran · GitLab
But I have verified the user and added him as a developer. How can we make sure that pipelines get run when a contributor submits an MR?
My understanding is that they have to submit a credit card to GitLab. That is a huge barrier of entry for new open source contributors. Is there no other way?
I asked on Twitter also: https://twitter.com/OndrejCertik/status/1431046013343526921
And also here: Preventing Crypto Mining abuse on GitLab.com SaaS - #24 by certik
Note: I think this is caused by a recent change in GitLab: Preventing Crypto Mining abuse on GitLab.com SaaS
It was suggested to me to simply use my own runners. Unfortunately that does not seem to work either.
I have disabled shared runners and setup a “Specific runner” and tested that it works when I create an MR:
Everything works. Then we tested from a new contributor:
And that does not work. The external pipeline (powered by Appveyor for Windows) works, but no GitLab-CI jobs get created, and consequently my specific runner has no jobs to pick up.
Does anyone know how to get my own runners working with new contributor’s MRs?
I might have figured out at least some workaround that will allow to get the MR tested from a new unverified contributor:
Setup “pipelines for merge requests”
Add the new contributor as a “Developer” to the parent project. This allows “piplines for merge requests” to run (they run in the parent project).
Ensure a specific runner (on our own hardware) is registered at the parent project and is up and running.
When this is done, the pipelines will run. Conclusions: you have to give the new contributor merge rights in order to run the pipeline. Unfortunate, but that seems to be the only option right now.
Suggestion: Allow to run the pipeline for merge requests manually from the parent project, even for unverified contributors, without giving the new contributor merge rights (yet).
We are running a short survey on potential alternate methods to validate accounts on free plans (other than credit or debit cards).
If interested, please fill it out here: https://forms.gle/jaqdocq6as24umdp8