Repository navigation
CI failing with error - Field 'canBeRebased' doesn't exist on type 'PullRequest' #910
Description
Activity
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
canBeRebasedfield. I guess we should introspect the server's GraphQL schema and adjust the queries we make according to which fields are present?I bet their GitHub Enterprise has an older version of the GraphQL schema that lacks this
canBeRebasedfieldsince 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.
i dont think the version above would fall outside the support range, even if we had a policy defined, but it made my mind revisit this thoughtedit: actually, according to https://github.com/proxy/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
canBeRebasedwas added to the GraphQL API on June 12, 2018. However, in GHES < 3.14 this field is a preview feature.Probably not the best idea but we could add this header to our GraphQL requests to enable
canBeRebased:Accept: application/vnd.github.merge-info-preview+jsonOtherwise, we would just have to conditionally omit the
canBeRebasedfield from our queries@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
Reacted by Matt Traviwe'll probably have to fix this issue even if we define a support policy
agreed. thanks for confirming
Otherwise, we would just have to conditionally omit the
canBeRebasedfield from our queriesThis 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.
Probably not the best idea but we could add this header to our GraphQL requests to enable
canBeRebased:Accept: application/vnd.github.merge-info-preview+jsonSo, I'd say we give this a shot IMO.... simply set the custom media type in the
Acceptheader by passing it in the appropriate option at the call of theoctokit.graphqlWhat'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
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".
Sure, how about we just remove the specific field
canBeRebasedfor now, It was only introduced to help filtering successComments/releaseLabels, but honestly who's consuming it at the moment!? 🤔we'll probably have to fix this issue even if we define a support policy
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!