fix: missing "PullRequest".canBeRebased field on GHES graphql api

[babblebey]

This Pull Request temporarily removes the canBeRebased field from the associatedPRs GraphQL query requested fields due to conflict with older GitHub Enterprise graphql api version.

Changes Made:

• Removed every instance of canBeRebased field consumption in the success script
• Appropriated field removal in test coverage

Related Issues

Resolves #910

[jedwards1211]

Have any of y'all tested things against a deployment of GitHub Enterprise Server before, even if not in CI, just manually?

I'm tempted to ask them if we can have a license for testing purposes and mess around with manually testing against it. I'd even be willing to figure out how to spin up temporary instance in AWS for CI testing and keep it in the free tier (I have experience using the AWS SDK) though I imagine y'all don't really want our CI tests to go that far.

[travi]

i've been in environments where GHES is the variation of GitHub available to the teams, but i have never spun up an instance specifically to test against. my understanding is that GHES is non-trivial to deploy, but i wont say i'm completely opposed to the idea if we could automate it to the point of being simple and low maintenance.

we go fairly far with the integration tests of the core repo to spin up a temporary npm registry, an api to simulate the github api, and a temporarily hosted git repo. i think we could take that further, too, if we gave it some more attention. that would be separate from this suggestion, but just highlighting it to suggest that something like you suggest isnt totally out of the question.

i do wonder if we could accomplish enough feedback from comparing our queries against the graphql schema for the various supported versions of the github api (at least the current version and the oldest supported version that shipped with GHES). i think that would give us quite a bit of protection for the changes that are happening recently without needing to stand up a full instance of GHES and figure out a suite of tests that would exercise the calls against that deployed api. the graphql schema wouldnt protect our calls against the REST api, but we could probably expand to do similar there if we decide this is successful.

to be open, this is a challenge i face with maintaining https://github.com/repository-settings/app/ as well, so i'm very interested in progress we could make that could protect both projects

[jedwards1211]

That's true we could check against the graphql schemas, as long as there's somewhere we can download old versions of the schema from

[github-actions]

🎉 This issue has been resolved in version 10.3.2 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[jedwards1211]

@gr2m I submitted a request ~10 days to GHES sales for a license to use for testing against, but I haven't heard back from them. Is that something you'd be able to pull some strings for? If we can get a license I'd be happy to work on trying to put together an integration test setup with it.