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
The ephemeral runner flow is now officially supported and with that they added a webhook to be notified when a workflow job is requested or changes state. This means that instead of the complicated polling logic that we currently have, we could just use the webhook to be told when the runner is done and needs to be replaced.
It also, of course, allows for runners to be spun up or scaled out on demand, if desired, based on the load, which could make for more efficient use of resources.
The one caveat with this is that, since it's a webhook endpoint, that will need to be exposed so that GitHub can connect to it, where the current implementation only requires outbound access from the runners to GH.
The text was updated successfully, but these errors were encountered:
I believe that autoscaling could be achieved by LXD Events as well. Given that containers shut down after a job gets executed, listening for one of the instance-shutdown, instance-stopped, or instance-deleted events could result in a new instance being spawned. All that without opening any firewall ports.
https://github.blog/changelog/2021-09-20-github-actions-ephemeral-self-hosted-runners-new-webhooks-for-auto-scaling/
The ephemeral runner flow is now officially supported and with that they added a webhook to be notified when a workflow job is requested or changes state. This means that instead of the complicated polling logic that we currently have, we could just use the webhook to be told when the runner is done and needs to be replaced.
It also, of course, allows for runners to be spun up or scaled out on demand, if desired, based on the load, which could make for more efficient use of resources.
The one caveat with this is that, since it's a webhook endpoint, that will need to be exposed so that GitHub can connect to it, where the current implementation only requires outbound access from the runners to GH.
The text was updated successfully, but these errors were encountered: