search

semantic-release / github

:octocat: semantic-release plugin to publish a GitHub release and comment on released Pull Requests/Issues
https://www.npmjs.com/package/@semantic-release/github
MIT License
407 stars 125 forks source link

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

Closed babblebey closed 4 weeks ago

babblebey commented 1 month ago

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:

Related Issues

Resolves #910

jedwards1211 commented 4 weeks ago

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 commented 4 weeks ago

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 commented 4 weeks ago

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[bot] commented 4 weeks ago

:tada: This issue has been resolved in version 10.3.2 :tada:

The release is available on:

Your semantic-release bot :package::rocket:

jedwards1211 commented 1 week ago

@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.