To try to approach a more intuitive behavior for jobs which apply
to tags but are defined in-repo (or even for centrally defined
jobs which should behave differently on tags from different branches),
look up which branches contain the commit referenced by a tag and
use that list in branch matchers.
If a tag item is enqueued, we look up the branches which contain
the commit referenced by the tag. If any of those branches match a
branch matcher, the matcher is considered to have matched.
This means that if a release job is defined on multiple branches,
the branch variant from each branch the tagged commit is on will be
used.
A typical case is for a tagged commit to appear in exactly one branch.
In that case, the most intuitive behavior (the version of the job
defined on that branch) occurs.
A less typical but perfectly reasonable case is that there are two
identical branches (ie, stable has just branched from master but not
diverged). In this case, if an identical commit is merged to both
branches, then both variants of a release job will run. However, it's
likely that these variants are identical anyway, so the result is
apparently the same as the previous case. However if the variants
are defined centrally, then they may differ while the branch contents
are the same, causing unexpected behavior when both variants are
applied.
If two branches have diverged, it will not be possible for the same
commit to be added to both branches, so in that case, only one of
the variants will apply. However, tags can be created retroactively,
so that even if a branch has diverged, if a commit in the history of
both branches is tagged, then both variants will apply, possibly
producing unexpected behavior.
Considering that the current behavior is to apply all variants of
jobs on tags all the time, the partial reduction of scope in the most
typical circumstances is probably a useful change.
Change-Id: I5734ed8aeab90c1754e27dc792d39690f16ac70c
Co-Authored-By: Tobias Henkel <tobias.henkel@bmw.de>
04ac8287b6