Requested check never run against ref

[karkir0003]

@progapandist I'm having this exact issue even when I change to using the master version and changing {{github.ref}} to {{github.sha}}. Any other fixes I can try?

[demberto]

Not sure if this is the same but I just had the same issue

- name: Wait for tests to succeed
   uses: lewagon/wait-on-check-action@v1.0.0
   with:
     ref: ${{ github.ref }}
     check-name: "Verify integrity"
     repo-token: ${{ secrets.GITHUB_TOKEN }}
     wait-interval: 10

with:
    ref: refs/tags/v1.1.1
    check-name: Verify integrity
    repo-token: ***
    wait-interval: 10
    allowed-conclusions: success,skipped
    verbose: true
/usr/bin/docker run --name cd98fd81a222fb56e4fecb8c85a926c2dc4b6_d5059e --label 4cd98f --workdir /github/workspace --rm -e INPUT_REF -e INPUT_CHECK-NAME -e INPUT_REPO-TOKEN -e INPUT_WAIT-INTERVAL -e INPUT_ALLOWED-CONCLUSIONS -e INPUT_CHECK-REGEXP -e INPUT_RUNNING-WORKFLOW-NAME -e INPUT_VERBOSE -e HOME -e GITHUB_JOB -e GITHUB_REF -e GITHUB_SHA -e GITHUB_REPOSITORY -e GITHUB_REPOSITORY_OWNER -e GITHUB_RUN_ID -e GITHUB_RUN_NUMBER -e GITHUB_RETENTION_DAYS -e GITHUB_RUN_ATTEMPT -e GITHUB_ACTOR -e GITHUB_WORKFLOW -e GITHUB_HEAD_REF -e GITHUB_BASE_REF -e GITHUB_EVENT_NAME -e GITHUB_SERVER_URL -e GITHUB_API_URL -e GITHUB_GRAPHQL_URL -e GITHUB_REF_NAME -e GITHUB_REF_PROTECTED -e GITHUB_REF_TYPE -e GITHUB_WORKSPACE -e GITHUB_ACTION -e GITHUB_EVENT_PATH -e GITHUB_ACTION_REPOSITORY -e GITHUB_ACTION_REF -e GITHUB_PATH -e GITHUB_ENV -e GITHUB_STEP_SUMMARY -e RUNNER_OS -e RUNNER_ARCH -e RUNNER_NAME -e RUNNER_TOOL_CACHE -e RUNNER_TEMP -e RUNNER_WORKSPACE -e ACTIONS_RUNTIME_URL -e ACTIONS_RUNTIME_TOKEN -e ACTIONS_CACHE_URL -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/PyFLP/PyFLP":"/github/workspace" 4cd98f:d81a222fb56e4fecb8c85a926c2dc4b6  "success,skipped" "Verify integrity" "" "refs/tags/v1.1.1" "***" "true" "10" ""
Checks running on ref:
Checks completed: Verify integrity ([3](https://github.com/demberto/PyFLP/runs/7270608385?check_suite_focus=true#step:4:3).10), Verify integrity (3.9), Verify integrity (3.8), Verify integrity (3.7), Verify integrity (3.[6](https://github.com/demberto/PyFLP/runs/7270608385?check_suite_focus=true#step:4:6)), Verify integrity (3.10), Verify integrity (3.9), Verify integrity (3.8), Verify integrity (3.[7](https://github.com/demberto/PyFLP/runs/7270608385?check_suite_focus=true#step:4:7)), Verify integrity (3.6)
Checks in_progress: publish
Checks after check_name filter:
Checks after Regexp filter:
The requested check was never run against this ref, exiting...

[nicknovitski]

I'm encountering this problem too and I'm pretty sure that it's because of pagination. Check out the api docs for listing check run s for a git reference, the method has this parameter:

per_page integer

The number of results per page (max 100).

Default: 30

You can see in the action's current source that it does not specify this value when calling check_runs_for_ref, so I assume it's using the default value of 30. We run more than 30 checks on some PRs, and I notice that when the problem occurs for us, the "Checks Completed:" output is only 30 items long, and missing the check I am depending on. @demberto, it looks like you also might be hitting that limit?

A simple fix would be to specify a higher per_page parameter, a better one would be to explicitly handle pagination, making multiple requests and combining the results if necessary.

[demberto]

I just place all dependant steps in a single workflow file nowadays.

[pingvinen]

I am experiencing this, because the jobs that I am waiting for, is itself dependent on other jobs (using needs), which Actions seems to handle by not actually creating the job until those other jobs have completed.

[melazrak]

I'm encountering this problem too and I'm pretty sure that it's because of pagination. Check out the api docs for listing check run s for a git reference, the method has this parameter:

per_page integer
The number of results per page (max 100).
Default: 30

You can see in the action's current source that it does not specify this value when calling check_runs_for_ref, so I assume it's using the default value of 30. We run more than 30 checks on some PRs, and I notice that when the problem occurs for us, the "Checks Completed:" output is only 30 items long, and missing the check I am depending on. @demberto, it looks like you also might be hitting that limit?

A simple fix would be to specify a higher per_page parameter, a better one would be to explicitly handle pagination, making multiple requests and combining the results if necessary.

We also have the same issue and I noticed that indeed only the first 30 checks are fetched and the check we are depending on is not in the first 30...

[lancerael-undo]

I got this to work using this change:

  -  ref: ${{ github.ref }}
  +  ref: ${{ github.event.pull_request.head.sha || github.sha }}

[brendanjryan]

#112

I think this PR should fix the issue ^

[nicknovitski]

Ah, yes, I was using version 1.0.0 of the action, and it looks like autopagination was added in 1.1.2. I can't prove that would have fixed my issue but it seems likely.