The Gatekeeper, or a project gating system
Go to file
James E. Blair 04ac8287b6 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>
2020-03-06 13:29:18 -08:00
doc Match tag items against containing branches 2020-03-06 13:29:18 -08:00
etc authentication config: add optional max_validity_time, skew 2019-12-10 16:39:29 +01:00
playbooks Fix py35 by pinning importlib-resources 2020-03-02 10:52:38 -08:00
releasenotes/notes Match tag items against containing branches 2020-03-06 13:29:18 -08:00
tests Match tag items against containing branches 2020-03-06 13:29:18 -08:00
tools Make most test cases work on MacOS 2020-02-20 12:59:38 +01:00
web web ui: fix buildset display when no builds 2020-02-28 11:06:21 -08:00
zuul Match tag items against containing branches 2020-03-06 13:29:18 -08:00
.coveragerc Revert "Revert "Switch to stestr"" 2018-05-17 08:33:40 -07:00
.dockerignore Add web/node_modules to dockerignore 2019-01-27 11:23:45 +01:00
.gitignore Fix ignored but tracked .keep file 2018-12-02 09:12:25 +01:00
.gitreview OpenDev Migration Patch 2019-04-19 19:25:28 +00:00
.mailmap Fix pep8 E127 violations 2012-09-26 14:23:10 +00:00
.stestr.conf Revert "Revert "Switch to stestr"" 2018-05-17 08:33:40 -07:00
.zuul.yaml Use explicit provides/requires for container jobs 2020-03-03 14:48:30 -08:00
COPYING Update README and add GPL license 2018-03-19 09:25:52 -07:00
Dockerfile Stream output from kubectl pods 2020-02-27 07:49:40 -08:00
LICENSE Initial commit. 2012-05-29 14:49:32 -07:00
MANIFEST.in Optimize canMerge using graphql 2020-02-28 09:43:56 +01:00
README.rst Support nodes setting 'auto' python-path 2019-09-19 10:28:53 +10:00
TESTING.rst Docs: fix stestr run example 2020-01-21 10:36:07 +01:00
bindep.txt bindep: fixed wrong dep names on rpm platform 2020-01-20 14:30:10 +00:00
requirements.txt Merge "Optimize canMerge using graphql" 2020-03-06 18:08:03 +00:00
setup.cfg Cleanup executor specific requirements 2019-04-04 08:58:04 +02:00
setup.py Partial sync with OpenStack requirements. 2013-09-25 15:30:37 -07:00
test-requirements.txt Optimize canMerge using graphql 2020-02-28 09:43:56 +01:00
tox.ini Don't set OS_LOG_DEFAULTS if unset 2020-02-17 21:41:00 +00:00

README.rst

Zuul

Zuul is a project gating system.

The latest documentation for Zuul v3 is published at: https://zuul-ci.org/docs/zuul/

If you are looking for the Edge routing service named Zuul that is related to Netflix, it can be found here: https://github.com/Netflix/zuul

If you are looking for the Javascript testing tool named Zuul, it can be found here: https://github.com/defunctzombie/zuul

Getting Help

There are two Zuul-related mailing lists:

zuul-announce

A low-traffic announcement-only list to which every Zuul operator or power-user should subscribe.

zuul-discuss

General discussion about Zuul, including questions about how to use it, and future development.

You will also find Zuul developers in the #zuul channel on Freenode IRC.

Contributing

To browse the latest code, see: https://opendev.org/zuul/zuul To clone the latest code, use git clone https://opendev.org/zuul/zuul

Bugs are handled at: https://storyboard.openstack.org/#!/project/zuul/zuul

Suspected security vulnerabilities are most appreciated if first reported privately following any of the supported mechanisms described at https://zuul-ci.org/docs/zuul/user/vulnerabilities.html

Code reviews are handled by gerrit at https://review.opendev.org

After creating a Gerrit account, use git review to submit patches. Example:

# Do your commits
$ git review
# Enter your username if prompted

Join #zuul on Freenode to discuss development or usage.

License

Zuul is free software. Most of Zuul is licensed under the Apache License, version 2.0. Some parts of Zuul are licensed under the General Public License, version 3.0. Please see the license headers at the tops of individual source files.

Python Version Support

Zuul requires Python 3. It does not support Python 2.

Since Zuul uses Ansible to drive CI jobs, Zuul can run tests anywhere Ansible can, including Python 2 environments.