Expected Checks aren't listed in gh pr checks or gh pr status

Describe the bug

To be honest, I'm not really sure that a bug report is right here! Please recategorize, close or move as you see fit!

My base branch pollicy prohibits merges when all checks aren't passing. I deleted a workflow file in a PR, and got GitHub into a bit of a stuck state where one of my checks was expected but wouldn't be run! While this is a weird state, I found it interesting that the CLI couldn't see this state. I would imagine that either gh pr checks or gh pr status would be able to detect that something is wrong with my PR, in the same way that the UI shows this information.

Steps to reproduce the behavior

ncx on  brendon_backfill_decisions [$?] via 🐍 v3.10.4 (sequoia_ncx) on ☁️  (us-east-1) took 19s
❯ gh pr checks
All checks were successful
0 failing, 50 successful, 0 skipped, and 0 pending checks

✓  name_of_check           7m5s    url
...

ncx on  brendon_backfill_decisions [$?] via 🐍 v3.10.4 (sequoia_ncx) on ☁️  (us-east-1) took 9s
❯ gh pr status

Current branch
  #1227  Given backfill decisions, remove ability to rea... [brendon_backfill_decisions]
  ✓ Checks passing ✓ 2 Approved

ncx on  brendon_backfill_decisions [$?] via 🐍 v3.10.4 (sequoia_ncx) on ☁️  (us-east-1)
❯ gh pr merge -r
X Pull request #1227 is not mergeable: the base branch policy prohibits the merge.
To have the pull request merged after all the requirements have been met, add the `--auto` flag.
To use administrator privileges to immediately merge the pull request, add the `--admin` flag.

ncx on  brendon_backfill_decisions [$?] via 🐍 v3.10.4 (sequoia_ncx) on ☁️  (us-east-1)
❯ gh pr merge -r --admin
Message: Required status check "cycle_close_plot_data / base" is expected., Locations: [{Line:1 Column:58}]

ncx on  brendon_backfill_decisions [$?] via 🐍 v3.10.4 (sequoia_ncx) on ☁️  (us-east-1) took 3s
❯ gh --version
gh version 2.11.3 (2022-05-25)
https://github.com/cli/cli/releases/tag/v2.11.3

Expected vs actual behavior

I put this above!

Logs

I put the logs above!

@BKDaugherty

@BKDaugherty I suspect this is a platform bug where the API is not returning information about the stuck check. Could you run gh pr checks with the GH_DEBUG=api environment variable set and paste the logs here, redacting any sensitive information, so that we can further debug what is happening?

❯ gh pr checks
[git remote -v]
[git -C . config --get-regexp ^remote\..*\.gh-resolved$]
[git symbolic-ref --quiet HEAD]
[git config --get-regexp ^branch\.brendon_help_debug_gh_cli\.(remote|merge)$]
⣾* Request at 2022-10-18 15:52:15.120107258 -0400 EDT m=+0.017311981
* Request to https://api.github.com/graphql
> POST /graphql HTTP/1.1
> Host: api.github.com
> Accept: application/vnd.github.merge-info-preview+json, application/vnd.github.nebula-preview
> DELETED AUTH TOKEN
> Content-Type: application/json; charset=utf-8
> Time-Zone: America/Caracas
> User-Agent: GitHub CLI 2.11.3

{
    "query": "\n\tquery PullRequestForBranch($owner: String!, $repo: String!, $headRefName: String!, $states: [PullRequestState!]) {\n\t\trepository(owner: $owner, name: $repo) {\n\t\t\tpullRequests(headRefName: $headRefName, states: $states, first: 30, orderBy: { field: CREATED_AT, direction: DESC }) {\n\t\t\t\tnodes {number,headRefName,statusCheckRollup: commits(last: 1) {nodes {commit {statusCheckRollup {contexts(first:100) {nodes {__typename...on StatusContext {context,state,targetUrl},...on CheckRun {name,status,conclusion,startedAt,completedAt,detailsUrl}},pageInfo{hasNextPage,endCursor}}}}}},id,state,baseRefName,isCrossRepository,headRepositoryOwner{id,login,...on User{name}}}\n\t\t\t}\n\t\t\tdefaultBranchRef { name }\n\t\t}\n\t}",
    "variables": {
        "headRefName": "brendon_help_debug_gh_cli",
        "owner": "ncx-co",
        "repo": "ncx",
        "states": null
    }
}
⣟< HTTP/2.0 200 OK
< Access-Control-Allow-Origin: *
< Access-Control-Expose-Headers: ETag, Link, Location, Retry-After, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Used, X-RateLimit-Resource, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval, X-GitHub-Media-Type, X-GitHub-SSO, X-GitHub-Request-Id, Deprecation, Sunset
< Content-Security-Policy: default-src 'none'
< Content-Type: application/json; charset=utf-8
< Date: Tue, 18 Oct 2022 19:52:15 GMT
< Referrer-Policy: origin-when-cross-origin, strict-origin-when-cross-origin
< Server: GitHub.com
< Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
< Vary: Accept-Encoding, Accept, X-Requested-With
< X-Accepted-Oauth-Scopes: repo
< X-Content-Type-Options: nosniff
< X-Frame-Options: deny
< X-Github-Media-Type: github.merge-info-preview; param=nebula-preview; format=json
< X-Github-Request-Id: (DELETED - not sure if personal lol)
< X-Oauth-Client-Id:  (DELETED - not sure if personal lol)
< X-Oauth-Scopes: admin:public_key, gist, read:org, repo
< X-Ratelimit-Limit: 5000
< X-Ratelimit-Remaining: 4999
< X-Ratelimit-Reset: 1666126335
< X-Ratelimit-Resource: graphql
< X-Ratelimit-Used: 1
< X-Xss-Protection: 0

* body is too long, skipping (contains more than 10000 bytes)
* Request took 697.160388ms
All checks were successful
0 failing, 48 successful, 0 skipped, and 0 pending checks
...

Is the body what we need here? Is there a way to get that?

@BKDaugherty

@BKDaugherty The body is the part that we need but we have confirmed that this is a platform issue andt thus there isn't anything to be done from the CLI perspective since the API doesn't return the data necessary to display these checks.

I believe I ran into a similar issue. I recently changed my workflows and now, the new PRs have checks that are pending and never run. But when I run gh pr checks and gh pr status the pending checks don't show up.

I understand this is a platform issue. Is this issue being followed here or in some other issue? Is there a workaround?

Problem solved for me. In my case, those pending checks were explicitly specified on repo branch protection rules. After exluding those checks from the required checks list, everythning went back to normal again.

@dmelo

@dmelo this is actually the same issue I ran into! It's fairly easy to get around this odd behavior by doing exactly as you suggested and removing the check from the branch protection rules. That being said, you need to have a good bit of understanding of what's going on to know that you need to do that! And, if you're only using the cli, it's hard to know that the check exists at all.

One way of making this more intuitive may be pulling the information for what checks are required in the branch protection rules and displaying that as a part of gh pr status or checks. That way the user can tell what they are missing from the cli alone

@BKDaugherty

@BKDaugherty , I agree completely. Even though I was able to solve the issue for me, the current UI could be improved, so that others (and possibly my future self) don't lose time and energy on this like I did.

For anyone who lands here with a PR stuck on "Expected — Waiting for status to be reported": since the API doesn't list required checks that never reported, I wrote a small read-only workaround. It compares the base branch's required checks (classic branch protection and rulesets) with the check runs and commit statuses actually reported on the PR's head commit, then names the requirements that have no result.

gh extension install builtbysharath/gh-pr-check-explainer
gh pr-check-explainer https://github.com/OWNER/REPO/pull/NUMBER

Where it can, it also points at the likely cause: a workflow paths/branches filter that excludes the PR, a job that was renamed, a check reported by a different GitHub App than the one required, or a success that only exists on an older commit. It only reads data through your existing gh auth and changes nothing. Matrix and reusable-workflow job names aren't expanded yet.

Disclosure: I'm the author. It's MIT-licensed and new, so if it gets your case wrong, an issue with the PR link would help: https://github.com/builtbysharath/gh-pr-check-explainer

resolve-thread reads what the base requires from the rulesets, so a c…

A withheld plain comment holds nothing, and a fix is green on its req…

Navigation Menu

Repository navigation

Expected Checks aren't listed in `gh pr checks` or `gh pr status` #6448

Describe the bug

Steps to reproduce the behavior

Expected vs actual behavior

Logs

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Expected Checks aren't listed in gh pr checks or gh pr status #6448

Description

Describe the bug

Steps to reproduce the behavior

Expected vs actual behavior

Logs

Activity

samcoe commented on Oct 18, 2022

BKDaugherty commented on Oct 18, 2022

samcoe commented on Oct 20, 2022

dmelo commented on Dec 21, 2022

dmelo commented on Dec 28, 2022

BKDaugherty commented on Jan 11, 2023

dmelo commented on Jan 17, 2023

builtbysharath commented on Oct 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Expected Checks aren't listed in `gh pr checks` or `gh pr status` #6448