summaryrefslogtreecommitdiff
path: root/zuul/change_matcher.py
diff options
context:
space:
mode:
authorJames E. Blair <jeblair@redhat.com>2018-06-27 13:51:56 -0700
committerJames E. Blair <jeblair@redhat.com>2020-03-06 13:29:18 -0800
commit04ac8287b62f5d66356977d971c2518836615086 (patch)
tree3345d06b435e7e8e252f36b8ff7fdfa4441bcd5f /zuul/change_matcher.py
parent1536b1b6748750679635347dfba6c41a3b5946d5 (diff)
downloadzuul-04ac8287b62f5d66356977d971c2518836615086.tar.gz
Match tag items against containing branches
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>
Diffstat (limited to 'zuul/change_matcher.py')
-rw-r--r--zuul/change_matcher.py28
1 files changed, 14 insertions, 14 deletions
diff --git a/zuul/change_matcher.py b/zuul/change_matcher.py
index a78836944..7d045894d 100644
--- a/zuul/change_matcher.py
+++ b/zuul/change_matcher.py
@@ -58,29 +58,29 @@ class ProjectMatcher(AbstractChangeMatcher):
class BranchMatcher(AbstractChangeMatcher):
+ fullmatch = False
def matches(self, change):
if hasattr(change, 'branch'):
- if self.regex.match(change.branch):
- return True
+ # an implied branch matcher must do a fullmatch to work correctly
+ if self.fullmatch:
+ if self.regex.fullmatch(change.branch):
+ return True
+ else:
+ if self.regex.match(change.branch):
+ return True
return False
if self.regex.match(change.ref):
return True
+ if hasattr(change, 'containing_branches'):
+ for branch in change.containing_branches:
+ if self.regex.fullmatch(branch):
+ return True
return False
-class ImpliedBranchMatcher(AbstractChangeMatcher):
- """
- A branch matcher that only considers branch refs, and always
- succeeds on other types (e.g., tags).
- """
-
- def matches(self, change):
- if hasattr(change, 'branch'):
- if self.regex.fullmatch(change.branch):
- return True
- return False
- return True
+class ImpliedBranchMatcher(BranchMatcher):
+ fullmatch = True
class FileMatcher(AbstractChangeMatcher):