I recommended GitLab to someone to share some small free/libre/open resources (Lilypond music notation files it happened to be). They told me about being asked for their credit card and “something about pipeline” and “something about identity verification” and all of this turns them off quite a bit.
Why is GitLab opaquely and unexpectedly asking for credit card? This is very poor UX that could make projects lose contributors.
Seems User validation required? answers this somewhat. But why is the credit card request happening when users aren’t using pipelines? Why not just have pipelines as a feature turned off, and make it so that the credit card prompt is triggered specifically by someone setting up a pipeline? Just say “we require credit card verification in order to use the pipeline feature”. That would be much more straightforward.
The fact that the credit card request came up for someone who doesn’t want to use pipelines at all and doesn’t even know what they are is really awkward.
This was in a response to industry-wide abuse from crypto miners who abuse and monetize free CI minutes for their own personal financial gain.
New accounts and trial users will need to provide a valid debit/credit card for verification before they can run CI jobs using GitLab.com shared runners.
A user impacted by this change has the following options:
Provide a credit or debit card and use the 400 free minutes with shared runners.
A user can also run pipelines without providing a credit or debit card if they use their own runner and disable shared runners for their project.
Decline to provide the card and continue to use many of the GitLab capabilities for free. In this case, any feature within GitLab that relies on our pipelines won’t work, such as: A pipeline (CI/CD generally), scheduled pipelines including on-demand DAST scans, defining your own pipelines, utilizing Auto DevOps.
This is the fundamental detail that seems to be a missed UX consideration.
I’m talking about a person who did not know what pipelines and CI even are and has no plans to ever use them at all. That sort of user shouldn’t even be presented with the credit-card verification.
It should be made totally clear that the credit-card verification is specifically to unlock access to CI and shared-runners. You shouldn’t show it to people who don’t choose to set up that feature. And if they accidentally click that, hitting “cancel” on that feature should be straightforward and obvious. And they should just understand that the specific feature is locked behind this verification wall. They shouldn’t worry that GitLab is trying to invade privacy or sell them on stuff otherwise.
I guess this is another (more basic) example of GitLab not understanding users’ needs. We also have examples of that in the licensing discussions, where GitLab seems to assume that evry user of an instance will be a developer (at least the seem reluctant to implement some sort of “guest” user, that can only do very little, but doesn’t cost money) - and a developer who will use all the features available (making them see a value in us getting more expensive licenses put down our throats).
Your users just wanting to share what is essentially data being seen as potential developers is IMHO another example.
Hi,
as a maintainer of several open source projects on Gitlab I run into the issue that the whole review process is broken due to the new “verification wall”. The reason is that you break the chain of trust:
You (Gitlab) trust me as a responsible user for many years now.
Adding (personally trusted) a user to a projects should automatically give them a trust level to be able to use shared runners when pushing/working inside these projects.
Disabling shared runners for forks of untrusted users is very reasonable. But inside trusted projects there are other developers that keep an eye on everything. And IMO most projects just give proven/trusted users the developer status and also quickly descrease the status of misbehaving people.
Of course I (naively) asked some people why they don’t just enter their credit card number.
The consent here is clear, two examples:
“Oh no i am not giving away my credit or debit details to gitlab. That would be serious security breach”
“these days people hack everything…i wouldn’t underestimate anyone with even the minute details”
Maybe Gitlab could at least amend some details of the trust / verification handling.
Just wanted to chime in that the onboarding user experience lately hasn’t been very smooth. A new Gitlab user is invited to be a group member via their company email, they notice they are not able to run pipelines, confused why they’re being asked for a credit credit when they were added as a member of a company group. Both resolutions are not ideal:
They enter their private card details to GitLab or
We share company card details to the new user to enter, this is not ideal either.
Thanks for your feedback. I recommend posting and discussing in the main feedback topic where team members working on the CI crypto abuse are subscribed to. Closing here to keep it in one place.