In our organisation we have a CE edition of Gitlab.
I installed gitlab runner on a host in the network version 15 and registered the runner with our GitLab instance.
The runner seems active and in GitLab when I hover over the green circle it says “last contact less than a minute ago” so I assume the connection is correct and gitlab can see the runner.
When I create a job, the status remains “pending” and gitlab says “This job is stuck because the project doesn’t have any runners online assigned to it.” but when I click on the CI/CD settings, the runner is online.
When I run the runner with the debug flag:
gitlab-runner --debug run
It keeps looping with following message:
Checking for jobs… nothing runner=wGsBxh3d
Feeding runners to channel builds=0
There are no error messages when I run the runner.
What could be wrong here?
Can you go into the project settings and under CI/CD make sure that
Enable shared runners for this project is enabled.
Assuming of course, under Admin → Overview → Runners is a shared one.
You can also check if your runner is allowed to run untagged jobs - you can do that under Admin and then edit it to see if that option is enabled.
The runner is a specific runner for the project and not a shared one.
I also don’t have admin access on the gitlab instance but I am owner of the project.
Is the untagged option something I can set on the runner or is that a gitlab config?
Can I perhaps do a test by tagging the job? How do I do so?
OK, so check under the project and see if the runner is actually connected to the project. Otherwise it won’t use it. If you configured the runner yourself, then this means you’re controlling it just from the project itself.
However, if it was added by your Gitlab Admin, you may want to ask them to verify the configuration and to ensure it can be used by your project. I have done this on mine and it works, so providing you do the same you shouldn’t have issues.
I’ve configured it myself on the project and gitlab seems to be able to find it.
Like I mentioned above, when I go into settings → CI/CD → Runners, I can see my runner listed there with a green circle that says “last connected less than a minute ago”. So that’s why I believe the config and connection is working.
Any updates on this? I seem to have the same issue. I have admin access to my CE GitLab and I’ve enabled shared runners for my project and my runner can run untagged jobs.
I’d say it’s about 50% of the time my runner will get the job and run it automatically. About the other 50% of the time the job will fail because “this job does not have a trace”. Once I press refresh, 50% of the time they will start executing… sometimes not.
The only thread I can see to pull on is I do occasionally see this warning when I run
docker logs gitlab-runner
WARNING: Checking for jobs... failed runner=xxxxx status=POST https://gitlab.custom.url/api/v4/jobs/request: 409 Conflict
I did self-sign my GitLab certificate in order to enable the container registry. Maybe some issue with my self-signed certificate?
I am also facing the same issue. Gitlab runner does not pickup the jobs automatically. The job stays in pending status for very long time (rarely picks up).
However when I pause and start the runner (from admin page) it picks up the job immediately and executes the pipeline. If I check gitlab logs it says no jobs to execute but actually a job is waiting to be executed.
Any help would greatly be appreciated.
I’ve got the same problem. This may have started happening after upgrading the server to 15.9.2. After the upgrade, I did try CI, and have run at least a handful of jobs quite successfully.
However, now, someone’s committed/pushed to a particular repo, and jobs are stuck in ‘pending’. I tried pausing and unpausing the runner in the admin screens, and sure enough the stuck jobs turned to clocks and the jobs looked to be starting. I’m not 100% sure, but I think it fell back to a “pending” state again. Another pause/unpause and it’s run again, this time to completion.
My runners were on version 15.5.0, so I’ve upgraded them to 15.9.1. I’m not sure it’s helped, but as it takes a few days to find out, maybe I just need to leave it a bit longer.
Can confirm the issue with macOS runners