Getting info on new releases of gitlab-runner

It’s easy enough to get info on new releases of GitLab itself (there’s an indication - if not turned off - in the admin area, an a blog with an RSS feed), but apart from the announcements of most/every new minor version of GitLab mentioning that a new version of the runner is released, I haven’t any way of finding out that a new version is released.

Is there an easy way? How do others handle keeping the runner up-to-date?

Hi @grove!

The gitlab-runner project is using the GitLab releases feature (Releases list)

You can get notifications for those releases - and that may be what you’d like here.

There’s also a Releases API that you could poll if you wanted to build any scripting around the releases.


Sounds right. I’ve tried, then we’ll have to see if I get an email when a new release is made.

Your installation seems different from mine – mine just installs it automatically. I get a message then, so I know to roll back if it’s blown up.

What’s your install method, and can we update that to save you some stress?

I install the gitlab-runner from the debian package, and I do not want automatic breakag^Wupdates.

Now GitLab runner 13.3 has been released, but I didn’t receieve an email, although I had " New release" checked under “Custom notification events” :frowning:

Hey @grove!

Send me a message in the forum with your email, and I’ll see what I can unearth in our notification systems.

When you posted - I signed up - and I got the email at my work address - I’ve now signed up with my personal account too for the next release.

Subject was: gitlab-runner | New release: v13.3.0
Sent Thursday August 20 ~3:04am (EDT display I think)

Hey @grove - following up your message here to keep the discussion in the community going - I just wanted to make sure your email was kept private. uses the MailGun service for outbound emails, and I definitely don’t see a Release notification for that date that went out to you - though other project notifications have gone out before and after.

Can you audit your notifications at and make sure that the notifications for are set to Custom? Or if it’s set to Global - that your Global notifications include New Releases? If it is Custom, it might be worth setting them back to Global and re-setting them to Custom and see if that triggers a reset.

It’s probably a good idea to keep email addresses private, and to keep the rest of the discussion in the open.

I’ve made a screenshot showing that notifications for gitlab-runner is set to “Custom”

And one showing that “Custom” (it’s the only project having “Custom”-setting) includes “New release”

My global notification level (that shouldn’t matter here) is set to “Participate”.

I’ve tried to change the setting from “Custom” to “Global” and back.

Now 13.4 is out and once again I didn’t get an email.

Maybe I should point out that asking support resulted in the creation of this issue:
Non-members of a project can subscribe to new release notifications but they will not be sent to them (#267523) · Issues · / GitLab · GitLab

Is the debian package especially hairy? I have a number of machines installed via package, and my updates are run nightly via cron. And I don’t really watch it anymore, not for months now, because it always just works.I have 5 or 6 gitlabs for different groups/orgs/locations, and they all update nightly by cron.

In fact, a lot of my machines are auto-patched, and I’ve done that on a succession of machines for 20 years, and I’ve really not needed to care. Either I’m getting really great results or you’re getting uncharacteristically bad ones!

Oh! I’m on PCLOS and CentOS/Rocky.

I’ve upgraded our runners via the Debian package many times and never had problems.

But my aversion to automatic breakag^Wupdates is with the concept, I do not want it, period.

Hey, I understand the aversion. My experience with debian was brief and onomatopoetic, so I can’t comment on its reliability or validation. After 20 years on the mix I’m using, though, I can say for sure that one can have updates without breakage.

Good luck, whatever you do!

Good for you. My experience is a bit different, especially when exercising less used code paths (we do that a lot at work, and while the packages typically work, those code paths sometimes get broken in updates. As late as this saturday (where my colleagues didn’t expect to work) one of the other teams in the company I work for had a problem caused by an automatic upgrade.

Good for my distro, you mean. 20 years without issue is really nice.