Support has just told me that currently “unvalidated” users will not automatically be “validated” once you upgrade to a paid plan (Premium). Is this true? Has no other company issues with this? How do you handle onboarding for new employees?
There’s little activity in this thread so either I’m missing something or everyone runs their own runners (sic!) …
How are companies supposed to add new employees to their GitLab.com projects? Can we at least use the same credit card details for all employees and wipe them from the accounts once they’re validated?
Hi, we also are having trouble onboarding a new team member on our company (group at Gitlab). All the new member pushes to our repos are failing (even when gitlab-ci.yml tells to do not trigger pipeline), and the member is being spammed by email at each push (also our pipeline page on gitlab).
I believe having a way to validate the group (the group owner account being validated, for instance) is the best, because we will not ask for every new team member to add credit card to their account, but it would be important that the CI/CD works for the group repositories.
CI/CD not working for some team member is not nice, but the fail message spamming is annoying.
When you guys have any news, please let us know
Btw, thanks for the awesome tool that Gitlab is.
This change is quite devastating for open source projects. All new contributors now cannot run a pipeline when they submit an MR, even after I added them as developers of the project. I reported it here: Pipeline for new open source contributors does not run, but got no response.
Does anyone know if hosting our own runners will fix this issue for new contributors? It seems the pipeline itself will not run, not just individual jobs.
What is disappointing to me is that I tested this exact use case before choosing GitLab as our place to host our open source project about three years ago. Now this feature was taken away. I don’t want to be asking every new open source contributor to submit their credit card: that’s an unnecessary barrier to entry. My goal is to grow the contributor base, and this feature is a major roadblock.
Is there a plan to fix it?
Is gitlab.com meant for hosting open source projects (among other things)? I am fine if the answer is no. In that case we can investigate self hosting (assuming this feature can be turned off) or moving to another service. However, I would appreciate some response from GitLab, the company, about the direction and recommendations for open source projects that host at gitlab.com.
@certik there is no problem with hosting open source projects. That has nothing to do with the issues of verification of new users to projects with credit cards. Unfortunately, this situation was caused by the people abusing Gitlab’s resources, and Gitlab had to take action to stop them from doing it. Nobody has taken anything away from you. It is understandable that Gitlab has to take some sort of action to stop people abusing their shared runners. Had they not done it, you wouldn’t be able to use the runners anyway, because of the abuse meaning they weren’t available since all the resources had been used.
Yes, you can disable shared runners, and run your own runners, and you wouldn’t need to verify anyone then. That would solve your problem and your open source devs would not need to verify themselves with a credit card.
Thank you. I will set that up. I was worried that the pipeline itself does not run, not just the jobs, but if you say that works, that would fix our problems. Thank you.
When we decided to use GitLab, open source contributors didn’t have to verify using a credit card and the pipelines on their MRs would run. That feature has been taken away. Do you not agree?
I understand why, you explained it well in your post why it was take away. They have the full right to take features away. My only issue is with the communication about it, as well as setting expectations in the past.
At that time, people were not abusing Gitlabs services by crypto mining on their shared runners. The credit card verification was added for new users. That means, that from the day that was activated, new users were required to verify. For everyone who was registered and using shared runners prior to that date, didn’t have to verify. The feature hasn’t been taken away, you can still use the shared runners, but are required to verify because of the people that were abusing the service. If you want to blame anyone for that, blame the people who were abusing Gitlab’s services. Had nobody abused it, then no-one would have been asked to verify, and it would have been the same as it was previously available without verification.
You are confusing the situation since nothing has been removed, no feature has been taken away. If shared runners had been removed entirely, and that nobody could use them - that is taking something away. They are still there for use, you just need to verify first - it stops people abusing Gitlab’s resources. It’s purely an additional step to verify valid users who will not attempt to abuse Gitlab’s services.
You can disable shared runners on your project and create your own runners, then nobody needs to verify, and you can do everything you want on your own, private runners.
I don’t use runners, I have my own Gitlab installation on my premises, and I adminster this. I have no need for runners, but all the information was communicated via Gitlab about the abusers on the forum and what was required to continue using their shared runner service via gitlab.com.
I hope that GitLab will be able to implement more humanistic approach by allowing existing members to validate new users, instead of forcing people to be validated by central banks.
I am not blaming anyone. I am happy that GitLab is doing what they do and that they provide pretty much all of the major parts as MIT licensed open source code. That is the main reason why we decided to use it instead of the competition. I do understand that if people were abusing the service, GitLab had to do something.
I am also not demanding them to fix anything or to do anything for me. They don’t owe me anything.
All I am saying is that the solution that they implemented does not work for me. A solution that would work for me can be as simple as giving me (the owner of the project) a button to say “run the pipeline of this new MR from a new contributor, I am taking responsibility for the result”. I am also happy to verify myself with a credit card, or whatever way they want me to verify. All I want is the experience to be very smooth and the barrier of entry to be minimal for new contributors to contribute code to our open source project.
You can disable shared runners on your project and create your own runners, then nobody needs to verify, and you can do everything you want on your own, private runners.
I am hoping this is true, I will experiment with this next week and report back. If this works, I’ll pay for runners on my own hardware or rent it online somewhere.
Just a suggestion: instead of requiring all new users to provide credit/debit card, can we have something like:
if unverified, CI minutes is limited to 60 minutes/month (and have a note that adding the credit/debit card number will verify their account and have a higher limit)
if verified, CI minutes is limited to 400 minutes/month
I wouldn’t try GitLab CI if they required a credit/debit card number at the beginning before I even know if it’s what I want
As a student myself, I don’t have a credit card nor a debit card and contacting the sales team is daunting, especially since the page is targeted towards companies, and not individuals
Essentially, the jobs do not get created, so my own runner has no job to pick up for new (unverified) contributors. The only thing that works is “external pipeline”, in our case powered by Appveyor for Windows.
At this point — is there any way to enable GitLab-CI, with our own runners on our own hardware, for new (unverified) contributors?
The way GitLab is trying to prevent crypto-miners doesn’t really make sense. Exploits are motivated by the money behind, and crypto mining DOES produce income.
In fact actual miners are more likely to provide a credit card for validation than anything else, legitimate open source project owners and SMB development teams are just collateral casualties.
This action only sends the message that we are not a priority for GitLab, while corporate clients and miners are where the money flows.
@vicary Nope, mining is an abuse of Gitlab’s services, and therefore if a miner does provide credit card information - Gitlab can then find out who that abuser is from the credit card billing details and take action against them accordingly. A miner who doesn’t want to get caught is not going to provide billing information and subsequently won’t be able to abuse Gitlab’s services.
@iwalker Appreciate the optimism. I work in the payment industry and have been fighting card issues constantly. The only thing matters here is the potential reward, if shared runner clusters are large enough, expect unreported (yet) fraud cards from T1 networks.
I am not surprised that the registration form in customers.gitlab.com doesn’t even have China as an option.
I gave access to one of my repositories to someone so she will be able to push code to that repository. So it is not a fork, it is my project and I already verified my account with a credit card.
However, unfortunately the pipeline won’t run unless she too adds her credit card. (And she does not have one.)
I understand that you need the owner of the repository to be verified with a credit-card, but another person? Even if she is a developer or a maintainer the project. This makes a lot less sense to me.
Thanks for the feedback @remcohaszing . GitLab team member here.
We considered requiring 2FA for new users, however, after further analysis we believed this would not do enough to deter abuse as some abusers are willing to manually register accounts and not only rely on automation. While I personally recommend 2FA for all users, some users do not prefer to use it.
We do collaborate with GitHub, other CI platforms, and other companies that see cryptomining abuse. This does help us all reduce abuse.
We are considering alternative methods to validate free accounts that don’t require a credit or debit card for those who don’t have one or do not want to provide one. Stay tuned.
I don’t believe this is how the process should be working on our side. Are you still having this issue? If so, can you open up a confidential issue with the details and tag me in it?
