Non-ephemeral runners with Autoscaling Runner Set

[jaygridley]

Hello, I am trying to migrate from RunnerSet to AutoscalingRunnerSet, but I am missing the option to make a non-ephemeral runner. Non-ephemeral runners are helpful in some scenarios. Is there or will there be support for non-ephemeral runners with AutoscalingRunnerSet?

[liolios]

We are in the same scenario, support for non ephemeral runners would really help us out.

[HenrikDK]

Same here we have a shared pipeline setup that requires a singleton runner instance to handle critical deployment tasks which cant be run in parallel, current limitations of actions runner scale set make it impossible for us to migrate this old runner.

While technically you could run a scale set with only 1 pod, the ephemeral nature makes it too slow in practice as theres 20 seconds startup time, and 20 seconds release time for each runner. Normally these are not a problem when using auto scaling, but when all you want is a singleton runner instance it limits execution to 1 job a minut.

[HenrikDK]

I have been looking at the runner and as far as i can tell the runner pods recieve their configuration through the jwt token in the ACTIONS_RUNNER_INPUT_JITCONFIG environment variable

The Go code is somewhat hard to grok for me, so I don't know how complicated it would be to allow override of one or more of these options in the helm chart.

@Link- sorry to bother you but could we get some input on this.

Is the ability to run as "non ephemeral" totally out of the question for the runner scale set?

[Link-]

It's currently not possible with scale sets to create long lasting runners. The ephemeral nature of runners was a core design decision from the get go.