Endless 'Waiting for a runner to pick up this job...'

[stukalo]

Hi, folks!
I'm trying to setup a workflows, but the runner doesn't start my job. I've requested ubuntu-latest and got a message Waiting for a runner to pick up this job.... I've canceled jobs and triggered it again for several times without success.
Could anyone give me a hint to what I should do in this case?

Also, it seems that time shows wrong value on UI

[airtower-luna]

The message looks like there might be a typo in the runs-on definition. But the wrong time indicates there might be another bug. If the workflow file is correct or you still have the same issue after fixing it, the best option is probably to submit a bug report.

[stukalo]

Thank you!

[MikeJansen]

Just ran into this myself. Was putting ubuntu:latest...

[caijianhong]

Thank you!

[swiknaba]

There is actually a quirk with how the YML file is parsed, and the order of some keys matters, see https://github.com/orgs/community/discussions/31587#discussioncomment-9893422

[HarimbolaSantatra]

Thanks! I typed ubuntu:22 instead of ubuntu-22.04.

[HollysCoder]

I think there is a typo. You typed ubuntu-lates. It should be ubuntu-latest

[tueda]

I had a similar issue with ubuntu-20.4 and struggled for a half day...

[ghost]

You must use "ubuntu-20.04" instead "ubuntu-20.4", that is your mistake

[tueda]

You are right. Then, the point is: if GitHub Actions could instantly give me an error with some adequate message, I didn't spend a half day.

[salamisodikiolawale]

Hello !, i have the same problem but for me :
When I launch my ci everything works fine with runs-on: ubuntu-latest but my runners does not detect

name: CI-CD

on:
  push:
    branches: [ "develop" ]
  pull_request:
    branches: [ "develop" ]

jobs:

  my-job:
      runs-on: ubuntu-latest
      defaults:
        run:
          working-directory: ./frontend

      strategy:
        matrix:
          node-version: [16.x]

      steps:
      - name: CHECK-OUT GIT REPOSITORY
        uses: actions/checkout@v3
      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node-version }}
          cache: 'npm'
          cache-dependency-path: '**/package-lock.json'
      - name: INSTALL DEPENDENCIES
        run: npm ci
      - name: BUILDING APP
        run: npm run build --if-present
      #- name: TESTINT APP
      #- run: npm test
      - name: Build & push Docker image
        uses: mr-smithers-excellent/docker-build-push@v5
        with:
        
          image: user/frontend    
          tags: latest
          registry: docker.io
          dockerfile: frontend/Dockerfile
          username: ${{ secrets.DOCKER_USERNAME }}
          password: ${{ secrets.DOCKER_PASSWORD }}

[kojix2]

I didn't realize until this page that I was using ubuntu instead of ubuntu-latest. Saved me a lot of time. Thank you very much.

[tueda]

Eventually, now ubuntu-18.04 (deprecated) enters the eternal waiting. It worked in March.

[airtower-luna]

That's because it isn't just deprecated any more, it's been removed. So any workflow using it can't ever get a runner. Update to a newer version, ubuntu-22.04 is the current one.

[airtower-luna]

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

[jtormey]

I just ran into this as well, with ubuntu-18.04. Would definitely prefer GitHub Actions to return an error if the runs-on config specifies an unsupported platform.

[pdfrod]

Just ran into it as well; my team was completely puzzled as to why the workflows were not running. A better error message would make a huge difference here.

[joeflack4]

I am using large runners. My problem was that I just created the runner, and it auto-assigns it to a group called "Default". But by default, all runners in this group do not allow you to run actions on public repositories unless you click the check box for "Allow public repositories".

[joeflack4]

Could we improve the UX on this?

If running action on public runner w/ no permissions, can we exit out and show an error message about such insufficient permissions? Or even better, deactivate the action button, preferably with a tooltip explaining why.

[foker]

might be better to move into a separated issue

[sahilrajput03]

For me I just stopped the worflow and started it again and it started working now. I think for the first push you need to do it twice to make it work! Thanks.

[sujitpursuit]

thanks! restarting did make it work for me too!

[VijayAllRounder]

it worked for me too,thanks

[jenrenia]

I couldn't run it until I added one blank line after the jobs:(Does anyone know if this really matters?)

[Maclenn77]

I'm experiencing the same issue, I have tried and review some of the things pointed out here, but still not working. I'm using an aws auto-generated template for lambdas, so I'm wondering if the issue it's one of "uses" file that are being referenced in the job.

So, this is the part with issues:

 build-and-package:
    if: github.ref == 'refs/heads/main'
    needs: [test]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: aws-actions/setup-sam@v2
        with:
          use-installer: true

      - name: Build resources
        run: sam build --template ${SAM_TEMPLATE} --use-container

In this part, the action is stuck:

Building codeuri: /home/runner/work/about_me/about_me/about_me runtime: ruby3.2 metadata: {} architecture: arm64 functions: AboutMeFunction
Fetching public.ecr.aws/sam/build-ruby3.2:latest-arm64 Docker container image........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
Mounting /home/runner/work/about_me/about_me/about_me as /tmp/samcli/source:ro,delegated, inside runtime container

When I check the logs, these are the messages:

2024-03-04T03:46:57.9991600Z Requested labels: ubuntu-latest
2024-03-04T03:46:57.9991913Z Job defined at: Maclenn77/about_me/.github/workflows/pipeline.yaml@refs/heads/main
2024-03-04T03:46:57.9992032Z Waiting for a runner to pick up this job...
2024-03-04T03:46:58.8924246Z Job is waiting for a hosted runner to come online.
2024-03-04T03:47:01.3614880Z Job is about to start running on the hosted runner: GitHub Actions 13 (hosted)

Not sure if it's related, but in the summary there is a warning:

TEST
Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: actions/checkout@v3. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.

I don't think so, as it seems that is a warning triggered by the previous job.

As other people pointed out, there's no hint about what could cause the problem. I'm new using Github Actions for CI/CD with AWS. This pipeline is for testing the configuration after following the docs of AWS and Github. I'm shooting in the dark right now, I don't know if the problem are permissions, configuration or anything else.

I would be thankful with anyone that could figure out what is causing the problem and also support people that pointed out that better error messages would be do a big difference.

--

[4Source]

I have a similar problem. I would like to run a job on ubuntu-latest, windows-latest, macos-latest. When I enter them individually everything starts but when I enter them together it just says "Waiting for a runner to pick up this job..."

name: Continuous Integration

on: 
  pull_request:
    branches:
      - master
    # paths: 
    #   - 'src/**'
  push: 
    branches:
      - master
    # paths: 
    #   - 'src/**'
  workflow_dispatch:

jobs:
  test:
    name: Run unit tests
    runs-on: [ubuntu-latest, windows-latest, macos-latest]

    steps:
      - name: Checkout repository 
        uses: actions/checkout@v4

      - name: Use Node.js "18.x"
        uses: actions/setup-node@v4
        with:
          node-version: "18.x"
      
      - name: Install Dependencies
        run: npm ci

      - name: Run Tests
        run: npm run test

[swiknaba]

Got the same issue, and my syntax and all defined values were valid.

Solution: remove new lines

in some places, new lines seem to break Github Actions completely.

I had to remove a new line after:

Good:

jobs:
  test:

Bad:

jobs:

  test:

as well as

Good:

jobs:
  test:
    strategy: xx
    runs-on: ubuntu-latest

Bad:

jobs:
  test:
    strategy: xx

    runs-on: ubuntu-latest

The VSCode Actions Plugin did not catch this as a validation error.

[Bulat-Ziganshin]

@swiknaba
may be, it adds "\n" to the string value? I found this problem when making a long string with ": >" syntax, and finally solved it with ": >-" variation, although YAML docs say it's not necessary

[MilesSpence]

For anyone else having issues with this I think the reason mine was not working was because I was on a GitHub Enterprise Server (GHES) and per this page: https://docs.github.com/en/[email protected]/actions/hosting-your-own-runners/managing-self-hosted-runners it says, "Note: GitHub-hosted runners are not currently supported on GitHub Enterprise Server. You can see more information about planned future support on the GitHub public roadmap." So I think you have to host your own runner.

[gilbitron]

For anyone else who ends up here, the issue for me was using custom labels for runners, which is now deprecated.

[swiknaba]

I've reached GitHub support and got the message attached below.

TL;DR: The order of some keys in the YML file actually matters.

=====

Thanks for contacting GitHub Support.

So, while the syntax is correct, the ordering is a little different to what we show in the guidelines in our documentation. The general convention when writing your yml files is to specify the type of runner for the job at the top level of each job in the workflow, directly under the job name. This means that the start of the job definition would look like:

jobs:
  azure:
    runs-on: ubuntu-latest

I agree that it's strange that one version works if you simply add a space, and it's also strange that the VSCode Github Actions Extension didn't show a validation error; however, this relates to another convention used in yml files: the - uses key is generally defined after a step name, so the definition of your steps should look something like the following:

steps:
  - name: Checkout code
    uses: actions/checkout@v4
  - name: init
    uses: opentofu/setup-opentofu@v1
    run: _do-some-magic_

=====

NOTE: re-ordering the uses-key solved the problem for me.

[sarnold]

We hit this today; turned out to be a silly/horrible typo in the compiler name in a matrix build. Better yaml checks and error message would definitely help save time and frustration...

[p69]

My workflow eventually stoped executing and hanging forever in queued state. I even haven't changed anything. I have no idea how to fix it.
Here is my yaml

name: Deploy to DigitalOcean
on:
  push:
    branches:
      - dev
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4
      - name: Set up SSH
        uses: webfactory/[email protected]
        with:
          ssh-private-key: ${{ secrets.DO_SSH_PRIVATE_KEY }}
      - name: Add DigitalOcean to known hosts
        run: |
          mkdir -p ~/.ssh
          ssh-keyscan -H ${{ secrets.DO_IP_ADDRESS }} >> ~/.ssh/known_hosts
      - name: Sync project files to server
        run: |
          rsync -avz --exclude 'deps' --exclude '_build' ./ ${{ secrets.DO_USER }@${{ secrets.DO_IP_ADDRESS }}:/${{ secrets.DO_USER }/apps/clicker
      - name: Set execute permissions on the script
        run: |
          ssh root@${{ secrets.DO_IP_ADDRESS }} 'chmod +x /${{ secrets.DO_USER }/apps/clicker/build_and_run_dev.sh /${{ secrets.DO_USER }/apps/clicker/docker/run_local_dev.sh'
      - name: Run the scripts
        run: |
          ssh ${{ secrets.DO_USER }@${{ secrets.DO_IP_ADDRESS }} 'cd /${{ secrets.DO_USER }/apps/clicker && ./build_and_run_dev.sh'

[gu3st]

Same issue for us!

[thiraphat-ps-dev]

me too !

[jeeeepp]

Same here. The issue back.

[Teja-Cuber]

I guess it has been resolved, it started working.

[Map987]

it worked

[myanpetra99]

well i currently have this issue

[MetaCrawler]

Aaand today it started for us.
No matter which ubuntu version we use.
Fails with latest as well as 22.04, 23.04. 24.04.

[matt335672]

We've now encountered this too. We're not using self-hosted runners.

I implemented the changes in @swiknaba's post. These worked fine for me in my account, but don't work when I push the changes to the project account.

Update: As of 2024-08-06 09:45 UTC everything here seems to be working again with our original YAML files.

[rym-dd]

Same here, all pipelines running on GitHub runners (not self-hosted) are stuck.

[ArnavWee]

Did it resolve itself or did you do something to fix it , facing the same issue

[dangdong163]

HI @ArnavWee i facing that issue currently. don't know why. it's ok for last 1 hour

[klonwar]

This problem appears and disappears for no reason. Github support has not helped so far :c

[klonwar]

Same for me with self hosted on ubuntu... It started not so long time ago, before it worked like a charm

sudo ./svc status shows Active: active (running)
In Settings -> Actions -> Runners it shows Status: Idle

But in action log Waiting for a runner to pick up this job...

Enabling and disabling a label in the github ui helps for a little time
How to fix this?

[dev-javid]

In case your repository is a public, make sure you allow access explicitly:

[dfernandezramos]

Is anybody experiencing this issue with self-hosted runners now? All I can see is that the CI gets stuck forever waiting the runner to pick the second job of the workflow until a new workflow is created. Then the old one gets unstuck, finishes, the new workflow gets stuck again on the second job and so on. In a nutshell, we need to trigger a new workflow to make the previous one pick the remaining job and finish.

It seems it only happens with our Windows self-hosted node. It does not happen with our self-hosted macOS node.

Our yaml files are exactly the same. This has never happened to us until yesterday.