Replies: 6 comments 3 replies
-
Bump. This is a feature we would like as well. |
Beta Was this translation helpful? Give feedback.
-
We would like this feature too. |
Beta Was this translation helpful? Give feedback.
-
I did triage this and, by trial and error, discovered that the following can be done as of self-hosted runner version
The following changes would be preferred:
|
Beta Was this translation helpful? Give feedback.
-
Note that doing this in the runner executable itself is the only reliable mechanism. You can kludge something together with pre script and post script and background processes, but it still is subject to race conditions where the runner receives a job as the timeout passes. This is not limited to ephemeral runners; this a problem with scaling down any kind of runner. |
Beta Was this translation helpful? Give feedback.
-
We would very much like this feature as well. the In our environment we spin up ephemeral runners on demand in response to the github workflow_job webhook and in some cases we use highly specific runner labels (which might include highly workflow specific information like commit id) to ensure that the runner in which the job gets executed precisely matches the originating github action workflow_job event. If the workflow gets cancelled these runners can sit around idly until they reach an execution timeout. We would like them to instead shutdown and unregister if they don't receive a job within ~a minute after being spun up. |
Beta Was this translation helpful? Give feedback.
-
Select Topic Area
Product Feedback
Body
Currently we are using ephemeral runners to pick up a single job and process it. We launch our runners on job triggers and expect them to immediately pick up the job and terminate after (ephemeral style). Because things happen, we have situations where our ephemeral runner instances wait/run indefinitely because there are no jobs to pick up (so much for ephemeral!). Such instances are burning our compute resources.
As part of configuring the GitHub Actions runner (e.g. ./config.sh), I would like to request a max wait timeout parameter that will be designated for picking up a job alone. If a job is not picked up by the ephemeral runner within the time threshold, then it should terminate. (The pick-up time should be independent of the time the runner needs to perform any optional self-update ops during load time.)
Beta Was this translation helpful? Give feedback.
All reactions