How do I always get the latest runner version?

[sd185434]

Hello everyone, hope everything is well. Me and my team are using the ARC as part of our github workflows, we manually input the runner version on our Runner Dockerfile like this: ARG RUNNER_VERSION=2.311.0. Up to Wednesday we were using 2.310.2 this was deprecated and the runners stopped working, I've had another look at the runner image https://github.com/actions/runner/blob/main/images/Dockerfile and it seems like it takes the version as an argument, I'm assuming that this version is gotten from somewhere, is there a way we can do the same without having to refactor our dockerfile for every update, i.e. get the latest ?

Thanks!

ARC is great 😄

[krische]

I ran into this same issue as well. I thought the default behavior was that the runner software is supposed to automatically update it self. But in my case, I am using the new Runner Scale Sets ARC stuff. I investigated the JIT secret that gets mounted to the runner pods and I see there is a "DisableUpdate":"True", in there. So it almost seems like runners created by the scale set disable the auto-update of the runner software.

This sucks for anyone like you and me that extends the official runner image, since it requires updating our own image to use the newer release.

[krische]

I can see in the code right here that it is hard coded to disable the auto update. Is there a reason for this? Can this not be an value on the gha-runner-scale-set chart?

[AnhQKatalon]

We are having the same issue. Until now, our self-hosted runner has stopped working because of this reason for three times. Each time, we need to build a new runner image manually and update the runner template as well.

Currently, this is very annoying and require our team to do the upgrade reguarly.

[pablool05]

Hi,

We have the same problem. The problem is that we work with many different Runners and we depends on it to auto-update if necessary.

If necessary, we can contribute by making a Pull Request making the changes in the code to make the DisableUpdate configurable here.

[Link-]

You need to regularly call our APIs to check for the latest runner release published here: https://github.com/actions/runner/releases and rebuild your image based on that.

Here's an example workflow that we use for ARC which you can get some inspiration from: https://github.com/actions/actions-runner-controller/blob/0bfa57ac504dfc818128f7185fc82830cbdb83f1/.github/workflows/arc-update-runners-scheduled.yaml#L14

Then you have to build your docker image by passing the updated runner version (and runner-container-hooks) like this: https://github.com/actions/runner/blob/ac89b31d2f0eb27e223f4e3c1480b6a144407e1d/.github/workflows/publish-image.yml#L62

Obviously, I personally don't recommend that you immediately and automatically upgrade your runner before checking the changelog for breaking changes. We usually have the automation open a pull request and if everything's good to go we merge it and build/publish a new image.

[joshua-reddish]

I think this should be called out in the docs for those coming from the legacy runner system. The expectation coming from ARC to RSS is that the runner version is updated when the runner connects to Github.

This requires an operational shift in how users manage their base runner images.

[tim-reply]

Images from summerwind did not require this and were updating automatically on start. There is also documentation that actively contradicts this your statement - https://docs.github.com/en/actions/reference/runners/self-hosted-runners#communication

When a new version is released, the runner application automatically updates itself when a job is assigned to the runner

Following this I'd assume that rebuilding image is not necessary.

[niodice]

Every other area where we use runners, this auto update is enabled by default. We are also running into this issue and it can easily cause an internal outage if left ignored.

Why not enable this update by default?

[danitfk]

Who came up with this approach to version support? 😆