You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have been running into an issue recently with our ephemeral runners. The behavior we were seeing was that a runner being spun up with an old version of the Github runner agent would update as soon as it was launched, and if this was in response to a scale-up lambda run, a race condition would occur that would prevent the triggering workflow from ever running since the agent update would take place first.
We thought to resolve this problem by using the disable_runner_autoupdate parameter as described here:
disable_runner_autoupdate: "Disable the auto update of the github runner agent. Be aware there is a grace period of 30 days, see also the [GitHub article](https://github.blog/changelog/2022-02-01-github-actions-self-hosted-runners-can-now-disable-automatic-updates/)"
This however does not seem to be working - we have seen the same behavior recently when our runners were configured to use an image with v2.318.0 of the Github runner agent, and the launched runners upgraded to v2.319.0 after launch.
I confirmed that the environment variable DISABLE_RUNNER_AUTOUPDATE is set to true on the scale-up lambda function, and in the opt/actions-runner/_diag/ directory on the launched runner, there were two log files - one each corresponding with v2.318.0 and v2.319.0, which I would not expect to see if this were functioning as intended. The scale-up Lambda function seems to try to add the parameter to the config here, but I haven't been able to tell from debug logs what the final configuration looks like that is used for the runner.
Hello,
We have been running into an issue recently with our ephemeral runners. The behavior we were seeing was that a runner being spun up with an old version of the Github runner agent would update as soon as it was launched, and if this was in response to a scale-up lambda run, a race condition would occur that would prevent the triggering workflow from ever running since the agent update would take place first.
We thought to resolve this problem by using the
disable_runner_autoupdate
parameter as described here:Reference
This however does not seem to be working - we have seen the same behavior recently when our runners were configured to use an image with
v2.318.0
of the Github runner agent, and the launched runners upgraded tov2.319.0
after launch.I confirmed that the environment variable
DISABLE_RUNNER_AUTOUPDATE
is set totrue
on the scale-up lambda function, and in theopt/actions-runner/_diag/
directory on the launched runner, there were two log files - one each corresponding withv2.318.0
andv2.319.0
, which I would not expect to see if this were functioning as intended. The scale-up Lambda function seems to try to add the parameter to the config here, but I haven't been able to tell from debug logs what the final configuration looks like that is used for the runner.Below is our abbreviated configuration:
The text was updated successfully, but these errors were encountered: