Feature Request: Add a wait timeout for GitHub Actions ephemeral runners to pick up a job.

[fduser1]

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.)

[triple3567]

Bump. This is a feature we would like as well.

[e10harvey]

We would like this feature too.

[ric-whitehead-bbc]

Bump

[e10harvey]

I did triage this and, by trial and error, discovered that the following can be done as of self-hosted runner version 2.316.0:

1. Set a timeout in the runner client. One must start run.sh in the background and then start a timer since run.sh is blocking.
2. If the timeout is reached, attempt to de-register the runner via:

/path/to/config.sh remove ...

3. Check the return code of /path/to/config.sh remove. If it is 0, exit with success. If it is non-zero, do not exit.

The following changes would be preferred:

1. Documentation of the above config.sh behavior, with examples.
2. Well documented public APIs in addition to config.sh, run.sh, etc.
3. A timeout option for config.sh.

[spamse]

I'm not sure this is what is being asked for, though I could be misunderstanding. The use-case is where the Runner applications has launched and is connected to the repository, awaiting a Job. If no Job picked up within the timeout period, then quit the application (at which point the normal ephemeral deregistration behaviour would occur).