Rebase xla job on top master before running CI build. (#36852)
Summary:
This PR tries to rebase on top of origin/master before building xla job.
I also saw a TODO in existing code which does a very similar thing (rebase on master for gcc5 jobs), so I just fixed the TODO by moving the logic into a separate step.
Currently the logic is:
For these gcc5 and xla jobs, we rebase on top of "target" branch before building.
- This only happens on PRs.
- "Target" branch is "origin/master" by default, but if it's trying to merge into a release branch, target branch will be the release branch.
- I made the "target" branch a param mainly it's allow us to rebase on `viable/strict` if we want. But after a second thought, how quickly `viable/strict` moves forward is not controlled only by xla job, and it's hard to predict how long the breakage will last if it's not moving. But we do have control over how long a xla breakage lasts on `origin/master` (which should be short since we monitor it closely). So I currently want to keep `origin/master` and move to `viable/strict` when it's super stable.
- There're jobs like `pytorch_paralleltbb_linux_xenial_py3_6_gcc5_4_build` which would fall into the rebase logic as well, but since those jobs doesn't run on PRs(so the old logic was essentially no-op), I didn't enabled the new logic on those jobs.
Pull Request resolved: https://github.com/pytorch/pytorch/pull/36852
Differential Revision: D21171747
Pulled By: ailzhang
fbshipit-source-id: 433ea0e14d030e2e0fa74d2ff4244327e9db7044
