Re-running workflow should check out latest PR merge about buildbuddy

[vadimberezniker]

A branch can be incompatible w/o introducing merge conflicts.
e.g.
person1 merges a change into master that changes a function definition from Foo() to Foo(string) in foo.go
person2 has a PR that adds bar.go that calls Foo() without the string argument.

If person2 does not have person1's change in their local branch, the PR check will pass and they will be able to merge their change.

[bduffany]

Summarizing my understanding here (for context) -- GitHub exposes a special ref refs/pull/:prNumber/merge which points to what the state of the base branch would be after merging. The feature request here would be to run against that resolved ref as the commit SHA for the workflow, rather than the PR commit SHA.

Seems like a reasonable thing to do, although I'm not sure if it matches the users' expectations.

[vadimberezniker]

The main purpose of the PR check is to make sure that a PR won't break master.

Not using the latest merge has two potential problems:

1. master was broken but is now fixed but user can't merge until they sync their branch even if the breakage had nothing to do with their change
2. if a change was merged into master that is incompatible with the PR it won't be detected by the PR check if the user has not pulled the incompatible change into their branch

(2) is the bigger problem

[bduffany]

One thing that mitigates (2) a bit is that GitHub doesn't let you merge a branch that's incompatible. I think it makes you resolve merge conflicts before you're able to merge, which means it'll run another CI check once you push up the merge resolution.