Pull Request behind the target branch causing issuesSee original GitHub issue
By comparing a PR that may not have been rebased against the latest changes to
master itself, graphql-inspector emits backwards compatibility warnings for any recently added fields, even though these fields won’t be removed by the PR. Although it’s possible to work around this by merging the latest
master whenever this happens, this is a bit of a faff, especially given that GitHub doesn’t provide a button for doing this unless there’s a merge conflict.
Are there any tricks that would allow graphql-inspector to avoid showing these red herrings?
- Created 4 years ago
- Comments:16 (13 by maintainers)
Top GitHub Comments
@wopian done, use
master and try to run Inspector Action on
pull_request event, when it’s on
push it won’t get a PR number. I would recommend to use
pull_request on PRs and
master branch or something like that.
I don’t understand why you want to do it. A Pull Request is defined to be merged into master, so you need to know if the PR won’t break anything. If you compare it to something different than what’s the point?
Could you explain a bit more? Maybe I don’t understand something?
Apologies @kamilkisiela, I managed to miss your reply here.
Suppose you have two developers, Bob & Sue, both working on the same codebase. They both pull the code at the same time to begin their work – let’s call the commit they start with
After a day, Sue commits a change where she adds a new field to the schema (
Person.age for arguments sake), so that the latest commit on
master is now
Bob then pushes a new feature that does not change the schema whatsoever, and so can’t possibly introduce a backwardly incompatible change. However,
graphql-inspector compares his commit (which does not yet contain
master, which does, and concludes that Bob is breaking backwards compatibility by removing the
Of course, he’s doing no such thing, and the problem is only that the latest version of
master (containing commit
#c1) was not merged into his branch before performing the comparison.
Hopefully that makes more sense now?