Bot account gets 'The pipeline failed due to the user not being verified'

Problem to solve

On gitlab.com SaaS, I have a group of projects where I want to run renovate-bot on a number of projects. This bot runs from a Pipeline and needs to access the GitLab REST API. I’m on the Free plan, so as far as I can tell, I can’t create Group Access Tokens or Project Access Tokens. The GITLAB_CI_TOKEN lacks scopes the right permissions and I can’t change these. If I understand correctly, I need to use a Personal Access Token.

However, now I can’t distinguish the actions of this bot from my own, and this gets confusing. So I created a second GitLab user, made it maintainer on my group and registered its PAT to use in the pipeline. Now the actions of the bot are at least distinguishable from my own.

But now I have a new problem: When the bot creates a merge request, a pipeline runs but exits with the error The pipeline failed due to the user not being verified. I don’t know how to resolve this. Both my own account and the bot user have a verified mail address. Neither have a credit card registered, if that matters. Both my personal user and the bot account have 2FA, if that matters.

I investigated setting up a self-hosted runner, but I’m getting conflicting information:

• In the Pricing FAQ, on the question “Can I bring my own GitLab CI/CD runners?” I read: “Yes, you can bring your own GitLab CI/CD runner with all plans”.
• But in the GitLab Runner docs, under the heading “Use self-managed runners”, I read that I can use these for the Free, Premium and Ultimate tiers, on the Self-managed offering, whereas for the GitLab-hosted runners, it’s the same, but I can also use them on GitLab SaaS.

I now don’t know if I can even register a self-hosted runner or not, let alone if this will resolve my original problem of the bot user not being able to create merge requests and run pipelines.

Versions

Please select whether options apply, and add the version information.

• Self-managed
• GitLab.com SaaS
• Dedicated
• Self-hosted Runners

Versions

• GitLab (Web: /help or self-managed system information sudo gitlab-rake gitlab:env:info):
• GitLab Runner, if self-hosted (Web /admin/runners or CLI gitlab-runner --version):

Helpful resources

1. Check the FAQ for helpful documentation, issues/bugs/feature proposals, and troubleshooting tips.
2. Before opening a new topic, make sure to search for keywords in the forum search
3. Check the GitLab and GitLab Runner projects for existing issues. If you encounter a bug, please create a bug report issue.
4. Review existing troubleshooting docs.

For using the shared runners on GitLab.com, a validation with a credit card is required. This is to prevent abuse, and the credit card won’t be charged. See the pricing FAQ for details.

A forum user posted the steps they took to resolve a similar problem on GitLab.com in Pipeline fails w/ deploy key "due to the user not being verified" - #2 by robotben

Bringing your own runner for GitLab.com works similar to registering a runner on a self-managed instance, with the difference that only group / project runners are available (instance on GitLab.com is reserved for GitLab admins, the infrastructure team).

After installing the runner in a VM, you’ll need to obtain a registration token from the GitLab UI (group or project). When using the runner registration CLI, point to gitlab.com as instance URL, and use the registration token. Details in Registering runners | GitLab

Once the runner is up and used by your projects, it won’t consume compute minutes from shared runners, and only use your infrastructure resources. It should solve your initial problem, although, verifying the account with a credit card to access the free compute minutes might be less expensive.

I was able to verify the bot account by navigating to the Build > Pipelines page for a project with a CI/CD pipeline, where I was prompted to go through the verification process.

The distinction between instance, group and project runners is now more clear to me as well. I’ll probably try to set one up to see how the performance differs from the shared runners.

Thanks for the support Michael!

Glad you solved it. Thanks for sharing the path for others looking for the same in the future.

Tip from my own experience: Self-hosted runners come in handy when you have resource intense CI/CD jobs, for example compiling code (C, C++, Rust, etc.), or long running tests. Or security requirements with OS, containers, etc. I sometimes fire up a VM in Hetzner Cloud or GCP using Terraform/OpenTofu or CLIs, depending on my workshops and tutorials. I’ve also started exploring GitLab Runner on a Raspberry Pi, but this is more a private hobby playground.

You can also combine usage of GitLab-hosted shared runners, and your own runners. Your self-hosted runners can provide tags which they are responsible for. When a job adds these tags, only the self-managed runners will pick up the jobs.