GitHub PR does not pass checks because github actions are stuck in "Expected — Waiting for status to be reported" despite checks passing and checks working, without change, in prior PRs.

[vtjballeng]

Select Topic Area

Question

Body

We have a standard set of checks for this and several other repos. The checks normally run and there are no issues. Recently this particular private repo PR did not automatically merge as it should have because 2 status checks were suck in the "Expected — Waiting for status to be reported":

Here are the branch protection rules which were have not been changed since the last successful PR merge and automation success:

The GitHub actions did run and the checks were passed:

We have not changed the scripts since the last successful PR merge which also had successful PR checks and automatically merged.

Are others seeing this? I see a similar discussion here but it seems less clear cut than our case where we have unchanged scripts that proved successful on prior PRs and our scripts ran successfully.

[vtjballeng]

Updates:

• Re-running the checks had no effect.
• Pushing any changes, updating the PR code, or any code level changes to the branch the PR is checking forces a new check that does allow the checks to pass and update properly in the PR.
• I've found the same issue in open PRs in other repos I manage from the past 5 days as well.

[piotrekkr]

Check if names in required checks are actual names of running jobs inside workflow triggered by pull_request event. GH is using workflow job names to identify what is required for PR. It can also be that you pr branch does not contain workflows that runs checks and you should merge default branch to your PR or rebase it on top of default branch so they appear and will be executed in PR.

// EDIT

Updated my answer. I was not super clear by writing "workflows". What I meant by this was job names in workflows.

[ew3361zh]

Thank you for this explanation @piotrekkr - I am having a similar issue to the OP. I have a couple questions if you don't mind:

How do you know GH is using workflow names to identify what's required for the PR (vs. workflow job ids)?

I ask because I have one workflow with 2 separate jobs and one of the jobs has a name and the other doesn't.
When I was selecting which jobs I wanted to be required status checks, the job ID popped up for the first job (the one with no name).

e.g.

  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  format_code:
(this job has no name, just this 'format_code' job id)
...
  lint_test_type_check:
    name: Lint, Test, Coverage, and Type Checking
...

So in my required status checks, I have "format_code" (the job ID for the first job) and "Lint, Test, Coverage, and Type Checking" (the job name for the second job). They are both stuck in Expected - Waiting for status to be reported.
I am going to add a name for the first job and see if that clears up the issue.
But I was just curious to learn more about whether job IDs could also suffice. What if I refer to both jobs by their job IDs or if there has to be a job name for the required status checks to be able to identify the jobs properly?

[piotrekkr]

@ew3361zh I updated my answer. I was not clear with my answer and wrote "workflows" instead of job names inside workflows. This is fixed in my answer.

More detailed explanation you asked for is below.

Job name is optional and if not provided GH will use job ID as job display name. This is why you sometimes see the ID in check select list and sometimes actual name. I always use names for jobs and steps because it is just looking better in GH UI and when browsing logs. I could not find actual mention about this in docs but I'm using GH Actions for almost 4 years now and this is the behavior I observed many times. You can actually test it yourself by creating new workflow triggered by pull_request event and adding two jobs one with name and one without. Then in repository rulesets or branch protection try searching using id of the job with a name. It should not be displayed in this list if job have name set. On the other hand job without name should be on the list with job ID.

Also job names are case sensitive in PR checks so if you change job name for example to Title Case you will need to update required checks list too.

// EDIT

Another note. Job names are cached from all pull_request events and custom check jobs for some time. You could have a job with just ID e.g. job-a and then you updated this job and added a name like

  job-a:
    name: My Job A

Then you need to push your change so it will actually trigger this new job on your pr. Then GH will "register" it and will show new job name on checks dropdown list. But old name will also be there and will be there for some time (idk how long exactly). If you have this old job name as required check for PR you should remove it and add only this new job name.

Remember that this action will block other pull requests that do not have your changes with My Job A yet. Old pull requests will still execute old job and GH will require this new one after you update branch protection rules.

It is important to inform everyone else that checks changes and they should merge/rebase their pull requests with latest code, otherwise they will be stuck waiting for non existing check run.

[ew3361zh]

Thank you, @piotrekkr, this all makes sense - I agree on the job name being more UI friendly.

As far as out of date/non-viable GH actions, we've got a stale PR or 2 in our repo with old GH actions that no longer exist or are in use which I'm trying to clean up. Update: removed those stale branches with stale GH actions and reran actions on one of my PRs and no change - actions are still running properly but they're not properly reporting to the corresponding status check protections.

Our required checks are both existing and viable GH actions which are successfully running but still not successfully reporting their success to our corresponding GH branch protections (just for main right now).

I am wondering if part of it is we have an automatic force-push involved in the first job which runs Black on our codebase and pushes the reformatted code to the PR and then job 2 is run on that second force-pushed commit.

I may just need to open a ticket on it since it seems like a somewhat specific set of circumstances we have.

I really appreciate your thoughtful and detailed response.

[vtjballeng]

Check if names in required checks are actual names of running jobs inside workflow triggered by pull_request event. GH is using workflow job names to identify what is required for PR. It can also be that you pr branch does not contain workflows that runs checks and you should merge default branch to your PR or rebase it on top of default branch so they appear and will be executed in PR.

// EDIT

Updated my answer. I was not super clear by writing "workflows". What I meant by this was job names in workflows.

@piotrekkr the names do match. I started typing them and GH auto-suggested the correct jobs in the required checks form. I selected them from the auto-suggestion rather than typing the rest in. The checks ran correctly with prior PRs and with an update to this PR and I use the same methodology in ~20 other repos with success.

It seems there was something that failed on the GH side in this and some of my other repos with a PR in the ~5 days before this discussion that is now corrected as far as I can tell.

[piotrekkr]

I am wondering if part of it is we have an automatic force-push involved in the first job which runs Black on our codebase and pushes the reformatted code to the PR and then job 2 is run on that second force-pushed commit.

@ew3361zh There is another "feature" of GH that may be the reason here. If you push to PR using GITHUB_TOKEN as auth it will not trigger any events in GitHub. So checks will never trigger. When pushing you should use normal user PAT which always work. This is kind of security feature to prevent endless event loops and is not that easy to find in docs.