It is a good question, and the answer is good to remember. TL;DR it runs against the merge commit from the moment you last pushed.
You can learn the answer by inspection of Jenkins logs and some knowledge of GitHub. See https://builds.apache.org/view/A-D/view/Beam/view/PR%20builds/job/beam_PreCommit_Java_Commit/8566/consoleFull which ran against 3802f63 from https://github.com/apache/beam/pull/10003 (which now has new commits) > git checkout -f 4a8cc693e1e23db09181a50d1ea7ec71d15d9e63 > Commit message: "Merge 3802f63f629325e0f50d7ee24e1ab721cdcb4972 into 22bd9b16a7f66f91f772fb1e619327c9484cef8f" You can see that it is a commit that merged 3802f63 from the PR into 22bd9b which is on master. You can also see reference in the logs to refs/remotes/origin/pr/10003/merge which is a commit that GitHub updates whenever you push to the branch. Kenn On Tue, Nov 5, 2019 at 6:37 PM Pablo Estrada <[email protected]> wrote: > Hi, > this may be a dumb question. Let's imagine a hypothetical case, where I > open a pull request against master. I wrote the change on top of COMMIT#11, > so: > > My branch: > COMMIT#11 -> MyCommit > > Let's suppose that master has received a bunch of new commits (and a fix > on COMMIT#12), so it looks like so: > > Master branch: > COMMIT#11->COMMIT#12->COMMIT#13 > > When I open my PR, I am asking to pull MyCommit on top of COMMIT#13; *but* > when PreCommits run against my PR, they run against my branch, right? > > So COMMIT#11->MyCommit. > > If I wanted to test my PR with a fix that exists in COMMIT#12, I would > have to rebase My branch to include it. > > Is my understanding correct? > Best > -P. >
