Add runner version specification

[YokojimaSkewers]

If we disable automatic runner updates, runners are subject to curse of deprecation:

Upon a new version of the actions/runner software being released
GitHub stop allocating jobs to runners on old versions after 30 days.

When it is deprecated, as an issue said, we have no choice but to turn it off and suffer long automatic updates every time a runner is up until this repository publishes a new release that updates the runner version.

I suggest adding a feature of the runner version specification.
With this, we won't wait for the new release anymore.

[Link-]

@YokojimaSkewers - You shouldn't have any observable impact from the release of 2.301.1. This release, even though it's published, it's not activated for all organisations or customers. We made sure to publish the new runner images before this release hits all end users.

Did your workflows stop working as a result of 2.301.1 or is this a pre-emptive report? If your workflows stopped, can you share the repository / org name that were impacted please?

[YokojimaSkewers]

I experienced this from December 2022 on Helm Chart release of version 0.21.1, where the runner version is v2.298.2, until Helm Chart release version 0.22.0 is released, where the runner version is 2.300.2.
The runners made logs saying "An error occurred: Runner version v2.298.2 is deprecated and cannot receive messages." and only restarted repeatedly without listening jobs.

[YokojimaSkewers]

Though it is working now with the new release 3 days ago, it was not so immediate that we don't suffer the impact of deprecation.

Sorry for this but I cannot share our repository because it is private.

[YokojimaSkewers]

Sorry, I found the cause of this problem and it is due to us.

We used our Dockerfile for RunnerDeployment. It starts

FROM summerwind/actions-runner:latest

and the runner version depended on this line.
summerwind/actions-runner:latest has been updated immediately after runner version is updated, but we didn't docker pull.
So we continued using the old version of summerwind/actions-runner:latest and runner.

[Link-]

Thank you for investigating this @YokojimaSkewers let me know if we can help any further

[YokojimaSkewers]

It's fine. It works with the latest summerwind/actions-runner image. Thanks for your support.

[WoodyWoodsta]

The current options we have for auto-update/no-auto-update leave a bit to be desired. As others have mentioned in a few places, we have a few options, with their consequences:

• Leave auto-update on:
  • Painfully long ephemeral runner startups as soon as GH releases a new version of the runner
• Turn auto-update off:
  • Possible deprecations
  • Dependant on summerwind images update cycle
• Auto-update a fork of the summerwind images in lockstep the gh release schedule and deploy to a private registry
  • Every consumer of arc has to do this

@YokojimaSkewers I'm interested to know why summerwind images are not updated in lockstep with the runner releases? Is this because they require testing to guarantee compatibility?

[YokojimaSkewers]

In our case, it was just a bug. We should have performed docker pull or put --pull option in the docker build but we didn't.

[WoodyWoodsta]

Sorry - I should have tagged @Link- :) I'm interested in why the maintainers have chosen not to release summerwind images in-line with the github runner versions.

[Link-]

The runner binaries release isn't available to everyone all at once. It's released in stages. We build and push new summerwind runner images as soon as we have a new runner binary release. We're automating the process but there is still a part of it that is manual which leads to a slight delay in publishing the runner container images. This delay is obviously not desired nor intended.

[WoodyWoodsta]

I was not aware they rolled the releases out - thank you for clarifying that! Sounds like everyone is doing the best they can!