Macos-10.15 jobs not starting due to ghost self-hosted runner

When trying to run a new workflow with some jobs on macos-10.15, those jobs are just sitting saying

Found online and idle hosted runner(s) in the current repository’s organization account that matches the required labels: ‘macos-10.15’
Waiting for a hosted runner in ‘organization’ to pick this job…

However, I’m not aware of our organisation using any self-hosted runners, and our billing plan doesn’t event allow it (“Organization self-hosted runners are not available for organizations on legacy per-repository billing plans”). How can I stop this rogue runner so that Github’s hosted runners will pick up the job?

1 Like

I’m having the same problem, and I’m on a free plan using “macOS-latest” in my action. (I don’t think a “hosted runner” is a self-hosted runner, by the way.)

I’m used to my jobs starting instantly, or almost instantly. Now I don’t know whether they will ever run. Sometimes I’ve tried cancelling the workflow and running it again, and I get an instant run. Other times it hasn’t helped.

Is there just a lack of machines available? Is there anything we can change that would make this work? Is it a bug?

Please advise.

This message doesn’t seem to report any error, on the contrary.

Don’t you have a control panel to check the status of your currently running jobs?

Workflow settings on any CI service can be tricky, especially if you push a lot of commits and end up piling up multiple jobs — first jobs are run first, so later commits might end up waiting for ages. I had similar problems with Travis CI, and then realized I could tweak the settings to ensure that new commits would cancel previous jobs, which solved the problem.

Each account/repository can only have so many jobs running at once, and having multiple jobs will slow down all jobs. Sometimes you might have to intervene manually to stop current jobs which might be looping and/or eating up resources and memory due problematic settings or other encountered problems.

CI caching can also speed up things, e.g. not having to install or update dependencies at each job run.

It does seem that if I wait long enough a build would start, and the situation has improved since I posted, so I guess it was just a temporary backlog in the Github-provided macos runners, plus a misleading status message.

Good to ear that.

I still advise you to look into your CI settings, to ensure that new commits terminate previous tasks (if this is Ok with your workflow), and to try an optimize the whole workflow by using caches, etc.

I mostly work with Travis CI, and experience has taught me that these kind of settings can make a huge difference (especially if multiple repositories use CIs, since they all add up into your available accounts resources for that service).

Good advice, but in my case I was dealing with a single push to a single repository, with nothing else happening in my account (or organization). Just one job… that took over an hour before it even started running… :frowning:

I’m hoping it’s better today, and this doesn’t become the norm.

We are having the same issue, same log for jobs that after 6 hours fail because they reach the limit waiting for the host:

2021-07-17T23:02:32.8125664Z Found online and idle hosted runner(s) in the current repository's organization account that matches the required labels: 'macos-10.15'
2021-07-17T23:02:32.8125733Z Waiting for a hosted runner in 'organization' to pick this job...

We don’t have other projects running tests on Mac, this is the only project and only one job is running at a time. Our project is open source, you can see now the idle jobs: Actions · medic/cht-android · GitHub

If you are still having issues launching AVD tests in MacOS virtual machines with the reactivecircus/android-emulator-runner@v2 action, maybe this is your problem: Job times out due to package id being in inconsistent location · Issue #168 · ReactiveCircus/android-emulator-runner · GitHub.

A workaround suggested there is to change the default value for target to google_apis:

          api-level: 28
          target: google_apis

Not sure if this was the original problem 3 days ago when I started to have issues in our CI pipelines because on that time I wasn’t able to see other log than the one posted above about idle hosted runner(s) ….