Endless 'Waiting for a runner to pick up this job...' #31587
-
Hi, folks! |
Beta Was this translation helpful? Give feedback.
Replies: 16 comments 13 replies
-
The message looks like there might be a typo in the |
Beta Was this translation helpful? Give feedback.
-
I think there is a typo. You typed ubuntu-lates. It should be ubuntu-latest |
Beta Was this translation helpful? Give feedback.
-
I had a similar issue with |
Beta Was this translation helpful? Give feedback.
-
Hello !, i have the same problem but for me :
|
Beta Was this translation helpful? Give feedback.
-
I didn't realize until this page that I was using |
Beta Was this translation helpful? Give feedback.
-
Eventually, now |
Beta Was this translation helpful? Give feedback.
-
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". |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
I couldn't run it until I added one blank line after the |
Beta Was this translation helpful? Give feedback.
-
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:
Not sure if it's related, but in the summary there is a warning:
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. -- |
Beta Was this translation helpful? Give feedback.
-
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..."
|
Beta Was this translation helpful? Give feedback.
-
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:
Bad:
as well as Good:
Bad:
The VSCode Actions Plugin did not catch this as a validation error. |
Beta Was this translation helpful? Give feedback.
-
@swiknaba |
Beta Was this translation helpful? Give feedback.
-
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/enterprise-server@3.9/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. |
Beta Was this translation helpful? Give feedback.
-
For anyone else who ends up here, the issue for me was using custom labels for runners, which is now deprecated. |
Beta Was this translation helpful? Give feedback.
-
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:
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:
===== NOTE: re-ordering the |
Beta Was this translation helpful? Give feedback.
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.