This change of policy / implementation of verification is a problematic issue for our new employees.
The announcement blog post mentions:
Prospects that are unable or unwilling to provide a card can reach out to sales for assistance
When doing so, sales simply replies with a canned response that more or less states that we “should stop using the shared runners and running our own runners instead”.
Our company is a “Consumption User” on the SaaS platform for which we purchase additional CI minutes every month. Telling your customers to stop using a the SaaS runners (for which they have paid) and run DIY runners does not seem like a customer friendly solution to me.
While I understand the reasoning behind wanting your customers to validate themselves to stop (crypto-)abuse the implementation of it is lacking in my opinion.
A credit-card is not as common in Europe as it is in America. Additionally: employees tend to not want to share/use their own personal credit/debit information for business usage. Most (if not all) of our employees create a dedicated GitLab account for business usage to keep business & personal separated.
Currently a user is unable to run any pipelines until they are “validated”. Even if those pipelines run within a group that has a positive number of CI minutes.
IMHO, the check should permit the pipeline to execute if the project is part of a group that has a positive number of CI minutes. Regardless whether the user triggering the pipeline (e.g. by creating a MR) is “validated” or not. Why does the user need to validate themselves if the CI minutes being used have been paid for already? If they want to be able to run pipelines under their personal account namespace or that of any groups they created themselves this could still require verification if desired.
This should still prevent (crypto-)abuse while also making it way more practical for companies/groups to keep on using GitLab as they were doing so in the past.