New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
More fixes for git baseline selection in pr-check #20216
More fixes for git baseline selection in pr-check #20216
Conversation
92d5afb
to
806578f
Compare
a0b6ab6
to
36055de
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've requested 2 cosmetic changes, and made a few sanity check comments. I'll approve once you ack / resolve all of them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM once the logging changes are made.
For posterity, here are the tests for the logic:
In all cases, the values returned by the modified function was the one we wanted |
Nice work with all the checks in #20216 (comment). One last corner case to verify: Reopen #20231 after one or more new commits have been merged to |
Done. Updated #20216 (comment) |
* More fixes for git baseline selection in pr-check * Fix typo * Use `master`, not `origin/master`, when choosing merge-base * Also print TRAVIS_COMMIT * Use TRAVIS_PULL_REQUEST_SHA instead of TRAVIS_COMMIT * Do not print TRAVIS_COMMIT * Address Raghu's comments
Turns out that
TRAVIS_COMMIT_RANGE
is frozen at the point of the PR's creation, not when the PR check is actually running.