Our GitLab installation used to not have https set up. And so when I registered a runner, it had http as the URL but recently we’ve configured the server to use https but now jobs aren’t getting picked up by the runner and is just getting a timeout error.
I went to GitLab Runner commands | GitLab to look at what I could do but from what it looks like, I might have to unregister and register the runner again? I don’t know if I want to do that because I want to keep all of the history of all the pipelines and jobs that we ran before.
Is there a simple way to keep the runner I had set up before but just update the URL to https?
Thanks for this, I wasn’t able to wait for a response since we have pipelines that needed to run right away so I unregistered the old runner and registered a new one. Unfortunately I don’t have time to test this out right now so I don’t know if your solution works but it does look promising.
On a side note, I have a bunch of old runners that I tried to delete but I was unable to. I think the main idea was I was unauthorized to delete them. I tried using my own user account, I tried using root - but still couldn’t delete them. If I delete those runners from
I do think that will work, and that’s what I’ve done before. @gregorip
Sometimes it can be hard to tell which runners are still connected, so I found it helpful to check /var/log/gitlab/nginx/gitlab_access.log for requests from UA gitlab-runner major.minor to see a real-time list of all the different Runner versions and corresponding IP addresses still “connected” or trying to ping your GitLab instance.
why is the new runner taking so long to pick up jobs?
This I’m not entirely sure of as there are a number of things that could cause this.
Are you using GitLab runner docker executor? If so, one good place to check for new latency/connection issues would be tailing docker logs for gitlab-runner while triggering a job that uses that runner.
docker logs -f gitlab-runner
now I have to wait minutes for anything to start.
I’ve encounterd this in the past and one or both of the following would remedy this issue:
stop gitlab runner and then restart gitlab runner
un-register and then re-register gitlab-runner (un-registering by deleting config.toml connection config or via UI/API)