fall back to using PR target branch when determining "merge base" between PR branch & target branch fails in test suite#11069
Merged
vanzod merged 2 commits intoeasybuilders:developfrom Aug 6, 2020
Conversation
…se', to avoid problems with git 2.28+
Member
Author
|
It seems that sometimes determining the "merge base" fails (without a clear reason), so falling back to just using the target branch is reasonable (it results in more "changed files" being reported, but that only slightly slows down the tests, it shouldn't result in other problems I think). Fixed in ac746c7 |
vanzod
approved these changes
Aug 6, 2020
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Some changes were made in Git 2.28.0 that break how we determine the list of changed files in PRs.
For example (from tests for #11068):
From https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.28.0.txt:
(hat tip @branfosj)
That basically means the triple dot (
...) notation we were relying on is no longer working.Can be fixed by determining the "merge base" between both branches first using
git merge-basebefore usinggit diff.edit: the changes to
git diffmay not actually be the cause of the problem here, it seems like determining the "merge base" is failing sometimes (reason unclear), see below