I found a workaround! You need to create a new PR for the same commit using different branch name. This will kick the build upon completion both original and new PR will get status update. Then you can merge the original and close the new one.

If PR was created from remote repository you can pull the ref to your repository locally by following these instructions:

• https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch origin pull/{id}/head:temporary
git push origin temporary

This can happen sometimes, what you can do is to push an empty commit to the branch of the PR. It will re-trigger all the checks you have in CI. This can be done using git command.

git commit --amend --no-edit

and then force push your branch.

git push -f

To amels. All that you need it is only rerun build for the branch. I did it for the PR in GitHub and it helped me.

For example. Go to Jenkins (or where is build can be managed manually) via details link and select your branch that relates to your pull request then push "Build Now" link. This action will rerun branch build. After the build will complete the merge button will became accessible.

It's working for me: close the stuck pull request and reopen it.

You have to somehow refresh the PR, I changed the base of the to PR to some other branch and then back to master and it worked.

No need to add empty commits. You can re-run the checks by adding the comment below in the PR:

/azp run

The simplest solution for me was closing the PR and opening it again. After that, checks where executed as expected.

There's a button on GitHub that makes it very easy.

One case we seen this happens consistenly is (for example): when github has required PR build, but in the stages there is no stage what actually runs on PR. So Imaging that we have just one stage but with condition that it runs only on push, cron, api but not on pull_request.

  include:
- stage: sample-stage
if: type IN (push, cron, api)
name: stage-name
script:
- mysript.sh

In this case, the travis will not run, at the github however will be:

Wating for status to be reported

As mentioned in question.

You can simply restart the jobs using the GitHub UI:

• Click on the Actions menu item. action_menu

• Click on your job.

• Click on "re-run jobs" rerun button

TL;DR

If this status check is necessary before merging, use a Personal Access Token instead of the default secrets.GITHUB_TOKEN for creating this PR in your github action:

- name: Create Pull Request
uses: peter-evans/create-pull-request@v3
with:
token: $\{\{ secrets.YOUR_PAT }}

If not, simply uncheck this under repo setting, in your protected branch:

Reasons

There're restrictions on github actions triggering other github actions, by design. So if you have the setting x must pass before branch can be merged, some actions could get stuck in limbo forever.

This is also why "push an empty commit" or "close and reopen the PR" can unstuck it--because then the PR is no longer purely action triggered. This is also why switching to PAT works, because using secrets.GITHUB_TOKEN implies this PR is github-action-initiated. While using a PAT, it's initiated by a user.

How to debug

I am not sure how to tackle this problem, how to debug this? There is no specific info than this: waiting for status to be reported

I find other people's debugging process generally more illuminating than the solutions themselves, so, glad you asked! Here's how I came to my conclusions:

• From googling "Expected — Waiting for status to be reported", I got to this top result, where ​I found the above setting change vaguely described in the comments.
• Then from reading the description of this setting, I understood it to mean that the reason I see this status is because I've configured for it to must pass before any branch can be merged, but for some reason this branch does not trigger it.
• So I considered what made this branch different from all the other branches that were triggering correctly. One big difference is that this PR is triggered by another action. Running with this theory, I googled "github action doesn't trigger when PR created by bot", and got this first result, which explained why.
• Finally I double checked other similar actions in other repos, and curiously, some action triggered PRs had runs below, but some don't. I compared their definitions, and noticed that the limboed ones were using secrets.GITHUB_TOKEN as token when creating PR, while the correct ones were using PAT. And indeed those PRs were headed by this octopus while the correct ones were headed by user icons:

Case closed.

For me nothing helped but waiting. The reason was that GitHub was partially down. Check for current status on https://www.githubstatus.com

In March of 2022, this still happens. Refresh your browser (cmd-R on Mac, F5 on Windows/Linux) first. That worked for me - hope it works for you!

I believe you need to double-check that the name of the job in the yml file is exactly the same as in Branch protection rule / Status checks that are required. Be aware it is case sensitive I spent some time fixing this issue but it turned out it expected build job to finish whereas I had Build

In my case it happened when the Workflow was not trigerring. I corrected the branch on which the action should be trigerred and then it worked

If there is conflict with master/main. In my case there was a conflict. I resolved that conflict and pushed another commit. It reworked as usual.

If your checks are starting and then getting stuck on pending , you need to look if the reported status checks are in a commit above that

for me a status badge that was pushed as part of my workflow, did not trigger the status checks to re-run

I had to add an ignore paths

on:
push:
# only trigger on branches, not on tags
branches: '**'
paths-ignore:
- '**/README.md'

When I did that it passed

For our situation it turned out that we had added the following ignore into our workflows because we didn't want the status checks (which are lengthy code scans) to run when changes were just occuring with our actual changes to our workflows.

    paths-ignore:
- '.github/workflows/**'

The problem was that the only changes were in the workflows folder and so the status checks are waiting for a run that will never happen. We had two solutions, one was to turn off those status checks for this PR or we removed the paths-ignore. We ended up removing the ignore and this kicked off the status checks (which are totally unnecessary) but it gets us past GitHub just waiting around forever.