Change Runner URL

GitLab CI/CD
1

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?

2

Hi @gregorip ,

You can configure the URL your runner uses to connect to your GitLab instance by editing the runner’s config.toml (found at /etc/gitlab-runner/config.toml by default).

Can you try changing http > https in the runner’s config.toml for the url value and verify if this changes the problem?

If you only use the runners on one gitlab instance, you could use the following sed command to update all the URLs automatically.

sed -i 's/url = "https:/url = "http:/g' /etc/gitlab-runner/config.toml
3 Likes
3

Hi @gitlab-greg ,

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

/etc/gitlab-runner/config.toml

Do you think that will work?

4

Also, why is the new runner taking so long to pick up jobs? Our old runner used to be able to pick up jobs very quickly - within seconds… now I have to wait minutes for anything to start.

5

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.

## real-time count
tail -f /var/log/gitlab/nginx/gitlab_access.log | grep 'gitlab-runner 1'
## aggregate
grep 'gitlab-runner 1' /var/log/gitlab/nginx/gitlab_access.log | awk '{print $1, $13}' | sort | uniq -c | sort -n

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)

I hope this helps. Let us know how it goes!

3 Likes
6

Thanks @gitlab-greg , everything here worked including the instructions to restart gitlab-runner. Now jobs are getting picked up right away. I appreciate all your help!

1 Like