I have a pull request, build passed on VSTS, but another check "Expected - Waiting for status to be reported" never succeeds, no matter how many times I try to trigger build. I had many other pull requests with no issues.
I am not sure how to tackle this problem, how to debug this? There is no specific info than this:
Where should I check first to resolve this?
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 --force-with-lease
git commit --allow-empty && git push better?
https://github.com/foo/bar/actions does not show any new actions being processed.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:
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.
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:
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.
GITHUB_TOKEN will make the action able to read/write on all repositories that the account has, right?
The simplest solution for me was closing the PR and opening it again. After that, checks were executed as expected.
There's a button on GitHub that makes closing the PR very easy:
And then, at the bottom of the page, the button "Reopen pull request" will appear, which reopens the PR (no comments, etc, are lost in that process):
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
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:
git fetch origin pull/{id}/head:temporary
git push origin temporary
For me nothing helped but waiting. The reason was that GitHub was partially down. Check for current status on https://www.githubstatus.com
I had a similar issue and it turned out that merge conflicts were my problem: "Workflows will not run on pull_request activity if the pull request has a merge conflict. The merge conflict must be resolved first.", like stated here: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request
It's working for me: close the stuck pull request and reopen it.
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.
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
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.
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.
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.
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
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
In my case the issue was that the search results contained two variants of the check names, one including the workflow name and one without.
Only the ones without the workflow name (i.e. validate-lambdas and validate-iac) worked for me - the other two just remained in Expected - Waiting for status to be reported status.
I did not want to disable the checks to fix this issue. But I disabled the Require status checks to pass before merging rule and enabled it again immediately.
Now when I checked the PR again the build passed.
In my particular case, I had the default build as the name build (16.x) (because I haven't given it a valid one).
When I edited the workflow file and gave it a new name Code Formatting, it wasn't updating the status check to reflect that the workflow succeeded.
To fix it, I had to go to the specific branch on GitHub -> "Settings" -> "Branches" -> "Branch protection rules", select "Edit" on the desired branch (mine was main) then under "Require status checks to pass before merging" type in the name of the job:
Afterwards, I selected "Re-run all jobs" and the status check was successfully updated. You could also add a new commit or force push as mentioned on other answers to get the status check from updating.
If you are using CLA-assistant to manage your CLA checks, you might also be able to do the following without interfering with GitHub settings, the PR, etc:
This re-ran the check that was stuck for me and completed successfully within a minute.
This can also happen if you have specified a pull request type and an unhandled action happens. In my case, I had the following:
on:
pull_request:
types: [opened, closed]
branches:
- main
and the error appeared when I added new commits to the PR, which required the synchronize type:
on:
pull_request:
types: [opened, synchronize, closed]
branches:
- main
So be careful when using types.
For those still facing the issue please check the following:
According to the Github docs here, you cannot have [skip ci] tags in your commits and require status checks unless you push a new commit.
You won't be able to merge the pull request if your repository is configured to require specific checks to pass first. To allow the pull request to be merged you can push a new commit to the pull request without the skip instruction in the commit message.
If your PR/commit is coming from another Github Action workflow and it doesn't trigger the Github action status checks it might be because of actions/checkout settings. It persists GITHUB_TOKEN credential which cannot trigger another workflow. Use the persist-credentials: false config to prevent this issue. Discussion here.
The auth token is persisted in the local git config. This enables your scripts to run authenticated git commands. The token is removed during post-job cleanup. Set persist-credentials: false to opt-out.
Don't skip running the render action using file filters. This prevents the workflow from getting triggered as mentioned in the docs here.
Due to path filtering, a pull request that only changes a file in the root of the repository will not trigger this workflow and is blocked from merging. On the pull request, you would see "Waiting for status to be reported."
I had the exact same issue as this post and many of you. I found the solution in a github forum, basically GITHUB_TOKEN won't create a workflow run, we have to use a PAT token and replace it so the workflow can run.
Link here: https://github.com/changesets/action/issues/187
rom GitHub docs:
When you use the repository’s GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN will not create a new workflow run. This prevents you from accidentally creating recursive workflow runs. For example, if a workflow run pushes code using the repository’s GITHUB_TOKEN, a new workflow will not run even when the repository contains a workflow configured to run when push events occur.
Use a repo scoped Personal Access Token (PAT) created on an account that has write access to the repository that pull requests are being created in. This is the standard workaround and recommended by GitHub. However, the PAT cannot be scoped to a specific repository so the token becomes a very sensitive secret. If this is a concern, the PAT can instead be created for a dedicated machine account that has collaborator access to the repository. Also note that because the account that owns the PAT will be the creator of pull requests, that user account will be unable to perform actions such as request changes or approve the pull request.
I tried closing and reopening the pull request (as suggested by Bernat), but that didn’t fix the issue. It remained stuck. The process only exited the “loop” after I modified an unrelated line in the action file, committed the change, and pushed it to GitHub. After that, the pull request automatically re-ran all the required checks, including the one that had previously been stuck.
Remove the check that is not completing and add it again by searching in the Branch Protection Rules check. it needs to be exactly named like the executed action.
Example:
Foo - Waiting for Status be reported...
and in your Actions Tab you have:
Bar / Foo ✅
THIS won't match and GH will wait forever to have something reported under the original name.
This is because you maybe refactored it to be run from a separate job or similar. Name didn't change, but now it's run below another, so the Branch Protection check has to match that change. I can be confusing at first, but actually its just logical, since the check refers to name that is displayed (no technical id here to reference). If the name changes, you have to also change the BPR rule. Best bet is remove the check and add it again via search and drop-down. Warining: it would still display the old name, since it caches all action names that have run for that Repo/PR.
I was in a private organization, forked a private repo and made a PR to the original repository. The CI status stayed at "Expected — Waiting for status to be reported" no matter if I force-pushed, rebased or closed+reopened the PR.
The solution in my case was not to make the PR from a forked repository, but by pushing to a branch in the original repository and make the PR from that branch. For some reasons, CircleCI did not build/pick up the changes from the forked repository.
No need to add empty commits. You can re-run the checks by adding the comment below in the PR:
/azp run
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!
