Self-hosted runner with github runner as backup (when offline)

Hello everyone!

I would like to know if it’s possible to have a self-hosted runner for a private repo that falls back to a normal github runner whenever the self-hosted runner is offline.

In my particular case, since I’m maintaining a private repo for a project where me and other collaborators write documents using LaTeX, I need to use a github action that uses a Latex Docker Image, which takes about 4-5 minutes to complete, and about 3 minutes just for setting up the actions everytime.

Testing a self-hosted runner capable of caching the actions, it takes less than 2 minutes to complete everything (setup, compile, etc.). Obviously, the problem occurs when (for any reasons) the self-hosted runner goes offline, and the pull_request checks are queued, causing the workflow to hold on for too much time.

So, is there a way to configure the YAML file in order to mainly use the self-hosted runner, and, in case, the github runner as backup?

9 Likes

This is not something we currently support.  I have added to our feedback queue to consider for a future update.

6 Likes

This would be immensely helpful for open-source projects, where self-hosted runners might help to add some execution speed and higher levels of parallelism, but you’d also want to have people who fork the repository be able to get the same CI tests run for their own branches without lots of setup overhead.

I just want to bump this and say that I second/third this opinion.

We could keep a $1000 EC2 instance running through the day, but we could shut it down at night.
We need many many more cores for parallel PHPUnit, and it takes around ~10 min currently on hosted Github runners.

On such an AWS instance we can get it down to 1-2 minutes easily. It makes a big difference.

But we could also save ~1/2 the cost by shutting it down on a schedule, and having a “fallback” would also provide us the ability to have it work without modifying Github workflows, if that instance is down for maintenance or whatever.

It could even be extended to “Is there available runners? Nope, go for Github”.

I think implementing the “runs on tag” as

runs-on: [self-hosted, ubuntu-latest]

Would work. I think that might be used for tags, but then make it a runs-on-priorties tag, or imlement it as a list / array of arrays.

runs-on: [[self-hosted], [ubuntu-latest]]

Or

runs-on:
    - [self-hosted]
    - [ubuntu-latest]

I think especially the array approach could be “fine”, as it could attempt the normal logic you are doing, fail within a timeout / on error, and then attempt the next “runs-on”.

2 Likes