-
Notifications
You must be signed in to change notification settings - Fork 619
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ephemeral Runners? #182
Comments
Thanks for creating the suggestion, and I really support this idea. Any idea for iimplementation. There are potential some caveats:
|
For similar reasons to the OP, this is a feature I also like. A related project, envoyproxy/ci-infra does this by having the runners in an ASG, and detaching on job start. |
Upvoting this as well. I don't want a bad job to leave behind stuff that could impact a future job. |
Would be great if we can support this strategy as well. Really like the idee. Hope I have the next months some time to do some experiments! |
It looks like there is a |
GitHub is also started with testing an event for workflow jobs to handle a better sclaing |
It looks like that the support for ephemeral was finally merged on actions/runner#660 |
It isn't clear whether or not the new |
is there anyone that can test the ephemeral flag with GHES? |
It has been confirmed in actions/runner#660 that |
What changes are required to implement this? I understand that it is not available for GHES but in other environments this would be amazing. https://docs.github.com/en/actions/hosting-your-own-runners/autoscaling-with-self-hosted-runners |
From the top of my head:
Of course all of this needs to be configurable and backwards compatible for GHES. |
It would be nice if the idle configuration meant how many runners should be registered and waiting for jobs. Every time one getsa job, the scale up lambda would register another. |
--ephemeral will ship in the next version of GHES (but as I said above it requires server changes to fix the race condition with client side only assignment) |
Implementing this is in progress. Closing this in favour of #1372. Will track the implementation of this there. |
Problem to solve
As a developer interacting with a public repository, I want to be able to have ephemeral instances so that I can safely use self-hosted runners in a public repo.
Intended users
Any public repository user where github actions are used, and the default github hosted runners do not provide sufficient resources.
Proposal
What does success look like, and how can we measure that?
The text was updated successfully, but these errors were encountered: