thanks for your answer.
I think the first two scenarios you outline do not cover my use case.
To be clear, I would not use a self hosted runner to setup a new self hosted runner. And I’m not saying it would be setup locally.
The basic workflow I’m thinking about would be something like:
- Job 1 (runs on a github runner), connects to cloud provider and creates new self hosted runner (e.g on GCP, AWS). This cloud hosted runner is configured to join the appropriate repository etc.
- Job 2 (runs on the cloud based self hosted runner), does some workload better supported by a self hosted runner (e.g large disc, large CPU workload, GPU, whatever).
- Job 3 (runs on a github runner) cleans up cloud provisioned runner.
What I observe when trying this is the workflow seems to fail and not do step 1, because the workflow requires a self-hosted runner so github won’t even start it.
If I pre-provision one self-hosted runner and then destroy it without removing the runner, it shows as offline, the workflow does now run. But Job 2 won’t start. Even when the provisioned self-hosted runner is online and fully available. It seems like github doesn’t continually recheck for a runner, it just checks once?
What I’m looking for is any further clarification as to when github checks if a self-hosted runner is available and what will cause it to get stuck.