CODEWITHSUNDEEP
githubgithub-actions
start
start

Reputation: 921

Error "Waiting for a runner to pick up this job" using GitHub Actions

When I use GitHub Actions with my config, there is a long waiting and it shows "Waiting for a runner to pick up this job".

What does 'runner' mean? And how can I resolve the problem?

Upvotes: 92

Views: 122135

Answers (15)

jgritten
jgritten

Reputation: 1003

Encountered this, this morning. After reviewing the workflow, seeing no changes for 12 months and having no deployment issues within the same time, I simply canceled and restarted the workflow. It Worked!. Guess Github was just having a Monday.

TL:DR - have you tried turning it off and back on again?

Upvotes: 0

kgalb
kgalb

Reputation: 103

Waiting for a runner to pick up this job

This error can arise from several different issues in GitHub Actions. As most folks have pointed out here, a typo or using a deprecated label (i.e., ubuntu-18.04) will throw this error as the service tries to get you a runner that matches that label, but there isn't one.

As we've been building Depot, we have been working on surfacing better error messages with our own GitHub Actions Runners so that you get way more information about what is actually wrong with your workflow. Also, surfacing those types of lint errors before the runner ever tries to pick up a job.

Upvotes: 0

Dhruv Prajapati
Dhruv Prajapati

Reputation: 1

Indentation matters a lot. I changed the indentation from 2 spaces to 4 spaces, and it got resolved.

Upvotes: 0

Buraxta
Buraxta

Reputation: 61

Sometimes, restarting the runner can resolve the issue.

Stop the runner:

./svc.sh stop

Start the runner again:

./svc.sh start

This can help refresh the runner's connection and resolve any temporary issues.

Upvotes: 0

Geraldo Novais
Geraldo Novais

Reputation: 2190

Answering your question:
'What are runners?'

A Runner is the machine/environment that executes jobs in a GitHub Actions workflow. For example, a runner can clone your repository locally, install testing software, and then run commands that evaluate your code.

Basically, we have:

  1. Self-hosted runner (It executes on your server or localhost)
  2. GitHub-hosted runner (It executes inside the GitHub platform)

To understand which one to pick, there are some considerations:

GitHub-hosted runner:

  • Managed by GitHub. You don't need to worry about setup.
  • Cannot directly access resources or perform actions on your localhost.
  • Limited to pre-configured software environments provided by GitHub.

Self-hosted runner:

  • Can access resources and perform actions on your localhost;
  • Can be customized with specific software environments and configurations;
  • Provides greater control and flexibility over the execution environment;
  • Requires setup and maintenance by the user.

Answering your second question:
"how can I resolve the problem?"

If you are using a Self-Hosted Runner, maybe you forgot to register the Runner inside GitHub. This can be one of the reasons you are waiting so long when the message 'Waiting for a runner to pick up this job,' appears.

If this is the case, see how to add a runner:
https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/adding-self-hosted-runners

You didn’t specify how your environment is configured, so it’s a little difficult to say what is really happening.

Here, I'll list some possible reasons:

  1. No runners: If there are no available runners, or they are busy with other jobs, your job will remain in the queue with this message.
  2. Runner configuration: The runner that is supposed to pick up your job might have configuration issues. Maybe incorrect setup or network problems between your runner and GitHub.
  3. Workflow syntax: If there are syntax errors in your workflow file, GitHub Actions might fail to parse it correctly and your job will remain in the queue.
  4. Permission issues: Be sure the user or service account associated with your GitHub repository has the necessary permissions to execute workflows and access resources required by your jobs.

Upvotes: 0

user7391567
user7391567

Reputation: 29

It worked for me once I added - uses: actions/checkout@v3 to steps property

Upvotes: -1

akop
akop

Reputation: 7845

The problem was caused for me because of this:

jobs:
  jobA:
    runs-on: ubuntu-latest
    environment: abc
    # ...

  # jobB hangs for ever and wont get started
  jobB:
    runs-on: ubuntu-latest
    environment: xyz
    needs: publish
    # ...

The solution was easy: I just removed the environments.

Upvotes: 0

Boris Dalstein
Boris Dalstein

Reputation: 7748

One potential reason might be that GitHub does not support anymore the operating system you're requesting.

For example, the following would not work:

runs-on: ubuntu-18.04

because GitHub stopped supporting Ubuntu 18.04 on April 1, 2023, see:

https://github.com/actions/runner-images/issues/6002

The solution is to use a supported operating system, for example:

runs-on: ubuntu-latest

For a list of supported operating systems, see:

https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners

Upvotes: 97

Rock_Artist
Rock_Artist

Reputation: 735

I don't know why, in my case it was runs-on: ubuntu-latest but got stuck. This is a free repo so it was strange.

After 3hrs I've cancelled the job and when I've re-ran it got a runner immediately. So it might also be something on GitHub's end.

Upvotes: 16

Amit Kadivar
Amit Kadivar

Reputation: 818

I have the same issue and it's like the runner was offline so you need to also check the runner status. I deleted the project folder from VPS so it's showing offline. so I will start again and then working fine

Upvotes: 0

zodiac1602
zodiac1602

Reputation: 31

I had a typo in my .yml file. I fixed it to runs-on: ubuntu-latest and now the runner is picking up the job.

Upvotes: 3

Itamar
Itamar

Reputation: 1338

Another reason this might happen is a wrong runner name under:

jobs:
  push:
    runs-on: [runner name]

Make sure it doesn't contain any typo, I was bashing my head for a few hours because of this the other day

Upvotes: 5

Martin
Martin

Reputation: 2581

This issue will also happen if you have not shared your self hosted runners with the repo correctly. The runs-on line is correct (i.e. there are other jobs with identical runs-on elsewhere that are working).

We have GitHub Enterprise runners and the team had correctly added them at the org level but had not authorised the specific repository to use them. It is obvious when you know because the runners tab for the repository is empty but confusing to the team because they did add the runners.

The solution is to go to the org, select the runner or runner group, click on the name, then select the repo from the list of available repos. You may also need to allow public repos or change the visibility of their repo as that also prevents runners being available to a specific repo.

Upvotes: 10

VivekDev
VivekDev

Reputation: 25389

In my case, it was petty mistake.

The runs-on was supposed to be ubuntu-latest, but was self-hosted. And it was waiting on it for ever.

jobs:
  Example-Actions-Job:
    name: Exploring GitHub Actions
    runs-on: self-hosted
    steps:

Upvotes: 8

Param Siddharth
Param Siddharth

Reputation: 958

If you misspell the requested runner's name after runs-on:, GitHub Actions won't explicitly tell you that you made a mistake. Instead, it will assume that a runner by that name exists and will continue waiting forever for it to be made available.

This is the most common reason why we face this error. Make sure you spell the operating system and architecture name correctly after runs-on:.

Upvotes: 34

Related Questions