CI failing with error - Field 'canBeRebased' doesn't exist on type 'PullRequest' #910
Comments
|
Thank you for reporting this... We will look into it. It appears this has something to do with GitHub Enterprise on Classic PAT Token. Here's a similar case but with another field cli/cli#5779 Cc: @gr2m @jedwards1211 |
|
@babblebey I bet their GitHub Enterprise has an older version of the GraphQL schema that lacks this |
since we havent run into problems like that for some time, we havent taken a step we probably should have taken a long time ago. we should define a support policy for GHES versions. starting with something along the lines of "EOL versions of GHES are unsupported here too" would probably be ok. we could point to a reference that lets folks determine which versions have reached EOL. we'd have to decide how GHES versions impact what we consider a breaking change too.
edit: actually, according to https://docs.github.com/en/enterprise-server@3.12/admin/all-releases, it looks like 3.9 is considered EOL accoding to GitHub. i know it is no small feat getting GHES upgraded and it is usually managed by another team, but you should really try to convince the team that manages your instance to get it updated @tejasbagal1 |
|
Probably not the best idea but we could add this header to our GraphQL requests to enable Otherwise, we would just have to conditionally omit the |
|
@travi GHES 3.11 isn't EOL yet and < 3.14 treats this field as a preview feature, so we'll probably have to fix this issue even if we define a support policy |
agreed. thanks for confirming |
This will not be a good option IMO haha 😃, Feels like plaster and duct-tape... What if another field surfaces?? Plus the fields at the moment are not even rich enough yet, this because we requested those fields in the first place to allow us build an object to replicate the issue/pull_request api response object as close as possible in order to aid filtering for successComment/releaseLabels. We might need to add more fields in the future.
So, I'd say we give this a shot IMO.... simply set the custom media type in the What'd you say @travi?? |
|
in general, we'll need to be careful to ensure that any fields that we use are available on all versions of the api that we consider "supported". public github and GHEC are simple because they are just whatever the current version supports. GHES is more complicated, even if we informally consider that to only be the GHES versions that have not been EOLed. i'm comfortable with using preview headers to make the request work as long as it works for that whole list (or it drives us to define the supported list more formally, and handling breaking changes). i think it is probably worth tracking an issue to remove the preview header once the versions that need it move into EOL. we've been pretty aggressive with supported node versions, but that is because those are generally simple for our users to configure on our own. GHES version is more out of the control of our direct users, so it would be difficult for us to justify aggressively dropping support for non-EOL versions. |
|
For those looking for a quick workaround, you can install the following versions of each packages with the following command: npm install -g semantic-release@24.1.0 @semantic-release/changelog@6.0.3 @semantic-release/commit-analyzer@13.0.0 @semantic-release/exec@6.0.3 @semantic-release/git@10.0.1 @semantic-release/release-notes-generator@14.0.1 @semantic-release/github@10.1.7 |
Sure, how about we just remove the specific field
This way we will be fixing this issue as @jedwards1211 as said |
|
🎉 This issue has been resolved in version 10.3.2 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Hello Team,
we use the latest version of semantic-release in our Jenkins pipeline.
After the recent update #874 in this repo, our build is failing with the below error
We are on GitHub Enterprise Server
3.9.19Please assist if any changes needs to be made to fix this. Thank you!
The text was updated successfully, but these errors were encountered: