-
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 😄 |
Beta Was this translation helpful? Give feedback.
Replies: 6 comments 2 replies
-
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 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. |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
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 |
Beta Was this translation helpful? Give feedback.
-
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: 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. |
Beta Was this translation helpful? Give feedback.
-
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? |
Beta Was this translation helpful? Give feedback.
-
Who came up with this approach to version support? 😆 |
Beta Was this translation helpful? Give feedback.
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:
actions-runner-controller/.github/workflows/arc-update-runners-scheduled.yaml
Line 14 in 0bfa57a
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 au…