Fix race related to PR with changed base branch

Some people use a workflow that's known as "stacked pull requests" in
order to split a change into more reviewable chunks.

In this workflow the first PR in the stack targets a protected branch
(e.g. master) and all other PRs target the unprotected branch of the
next item in the stack.

    E.g. master <- feature-A (PR#1) <- feature-B (PR#2) <- ...

Now, when the first PR in the stack is merged Github will automatically
change the target branch of dependent PRs. For the above example this
would look like the following after PR#1 is merged:

    master <- feature-B (PR#2) <- ...

The problem here is that we might still process events for a PR before
the base branch change, but the Github API already returns the info
about the updated target branch.

The problem with this is, that we used the target branch name from the
event (outdated branch name) and and the information from the change
object (new target branch) whether or not the target branch is protected
to determine if a branch was configured as protected.

In the above example Zuul might wrongly conclude that the "feature-A"
branch (taken from the event) is now protected.

In the related incident we also observed that this triggered a
reconfiguration with the wrong state of now two protected branches
(masters + feature-A). Since the project in question previously had only
one branch this lead to a change in branch matching behavior for jobs
defined in that repository.

Change-Id: Ia037e3070aaecb05c062865a6bb0479b86e4dcde

0 files changed, 0 insertions, 0 deletions