Check running against incorrect pull request

[LukeZeller]

Issue workflow progress

Progress of the issue based on the
Contributor Workflow

• 1. The issue provides a reproduction available on GitHub, Stackblitz or CodeSandbox

  Make sure to fork this template and run pnpm generate in the terminal.

  Please make sure the Codegen and plugins version under package.json matches yours.

• 2. A failing test has been provided
• 3. A local solution has been provided
• 4. A pull request is pending review

---

Describe the bug

In specific cases, the check is running against changes on the wrong pull request.

In the output, I see: EXPERIMENTAL - Using Pull Request refs/pull/<WRONG PR #>/merge

It appears the issue stems from this code:

graphql-inspector/packages/action/src/git.ts

Line 35 in 27edee1

return result.data.length > 0 ? result.data[0] : null;

This github API returns a list and will return every PR for which the current commit is an ancestor. There's no guarantee that the first PR returned in the list will be the correct one. I confirmed by hitting the GH endpoint directly w/ the same commit that the check ran against; multiple PRs were returned and the first value in the list was the PR <WRONG PR #> which was not the PR that the action was being run against.

To Reproduce Steps to reproduce the behavior:

Create a stack of 2 or more branches & associated pull requests
main -> commit1 (branch1 / PR 1) -> commit2 (branch2 / PR 2)
When you hit the github API endpoint referenced above for commit1 both PR 1 and PR 2 will be returned. If PR 2 is listed first, then the action will break. I wish I could give a more exact repro but its not clear to me how Github orders the results (and as far as I can tell the return order is not documented and so shouldn't be depended on). In this case, the PR stack I'm working on has been manipulated / reordered some so that could've affected the order in which PRs are returned (relative to the order of the commits).

Expected behavior

When run as a pull_request event, the check should always be using the schema changes between the current PR its run against and the base branch for that PR. For pull_request events, Github explicitly provides context on the PR so inferring w/ the Github API as is done currently shouldn't be necessary.

Environment:

• OS:
• @graphql-inspector/...: master
• graphql:
• NodeJS:

Additional context: