When using a branch and pull model on a shared repository there are
usually one or more protected branches which are gated and a dynamic
number of temporary personal/feature branches which are the source for
the pull requests. These temporary branches while ungated can
potentially include broken zuul config and therefore break the global
tenant wide configuration.
In order to deal with this model add support for excluding unprotected
branches. This can be configured on tenant level and overridden per
It exists only for py2/py3 compat. We do not need it any more.
This will explicitly break Zuul v3 for python2, which is different than
simply ceasing to test it and no longer declaring we support it. Since
we're not testing it any longer, it's bound to degrade overtime without
us noticing, so hopefully a clean and explicit break will prevent people
from running under python2 and it working for a minute, then breaking
As we expand the Github driver, we're seeing a need to specify driver-specific
pipeline requirements. To accomplish this, bump the require/reject pipeline
keywords down a level underneath connection names. This lets users specify
per-source pipeline requirements.
This adds new API methods for sources to create the new pipeline filters
(by returning instances or subclasses of RefFilter, which used to be called
This change also creates and/or moves driver-specific subclasses of EventFilter
and TriggerEvent in(to) their respective drivers.
Instatiations of sources all passed (driver, connection) to the
constructor, which was expecting (config, connection). The
config option is currently ignored (sources currently have no
additional configuration), which is why we didn't notice the
Update the constructor to (driver, connection, optional config)
to match the rest of the driver-related classes.
This change, while substantial, is mostly organizational.
Currently, connections, sources, triggers, and reporters are
discrete concepts, and yet are related by virtue of the fact that
the ConnectionRegistry is used to instantiate each of them. The
method used to instantiate them is called "_getDriver", in
recognition that behind each "trigger", etc., which appears in
the config file, there is a class in the zuul.trigger hierarchy
implementing the driver for that trigger. Connections also
specify a "driver" in the config file.
In this change, we redefine a "driver" as a single class that
organizes related connections, sources, triggers and reporters.
The connection, source, trigger, and reporter interfaces still
exist. A driver class is responsible for indicating which of
those interfaces it supports and instantiating them when asked to
Zuul instantiates a single instance of each driver class it knows
about (currently hardcoded, but in the future, we will be able to
easily ask entrypoints for these). That instance will be
retained for the life of the Zuul server process.
When Zuul is (re-)configured, it asks the driver instances to
create new connection, source, trigger, reporter instances as
necessary. For instance, a user may specify a connection that
uses the "gerrit" driver, and the ConnectionRegistry would call
getConnection() on the Gerrit driver instance.
This is done for two reasons: first, it allows us to organize all
of the code related to interfacing with an external system
together. All of the existing connection, source, trigger, and
reporter classes are moved as follows:
zuul.connection.FOO -> zuul.driver.FOO.FOOconnection
zuul.source.FOO -> zuul.driver.FOO.FOOsource
zuul.trigger.FOO -> zuul.driver.FOO.FOOtrigger
zuul.reporter.FOO -> zuul.driver.FOO.FOOreporter
For instance, all of the code related to interfacing with Gerrit
is now is zuul.driver.gerrit.
Second, the addition of a single, long-lived object associated
with each of these systems allows us to better support some types
of interfaces. For instance, the Zuul trigger maintains a list
of events it is required to emit -- this list relates to a tenant
as a whole rather than individual pipelines or triggers. The
timer trigger maintains a single scheduler instance for all
tenants, but must be able to add or remove cron jobs based on an
individual tenant being reconfigured. The global driver instance
for each of these can be used to accomplish this.
As a result of using the driver interface to create new
connection, source, trigger and reporter instances, the
connection setup in ConnectionRegistry is much simpler, and can
easily be extended with entrypoints in the future.
The existing tests of connections, sources, triggers, and
reporters which only tested that they could be instantiated and
have names have been removed, as there are functional tests which
Expose the ability to refresh a change in zuul/connection/gerrit.py
too, which is needed for our unit testing.
Signed-off-by: Paul Belanger <email@example.com>
This lets us ask a source for all of the branches for a project.
This uses the git protocol for now, but this can get much nicer
in the future if we switch to using Gerrit's REST API. It should
also be easy to do with github.
The included comment indicates why it's being added -- implementation
to follow in subsequent changes.
The connection registry should not have to know about the scheduler,
rather, the inverse is true.
(NB, connections themselves still know about the scheduler, but
that's okay, that happens after the connection registry is created.)
Drivers should be able to access the global configuration when
being created, so store that when the connection registry configures
Sources and connections are very tightly coupled in reality. Rather
than trying to maintain them as two abstractions, consider the
connection to hold all of the information and logic about the reality
of the external resource it represents. Make sources mere local
data structures that are used to interface a connection with a pipeline.
As seen in subsequent changes, this will allow us to simplify the
interconnections between objects.
Add reconfigure test case. This test previously fails currently due to a
regression introduced with the connections changes.
Because multiple sources share a connection, a pipeline that does not hold
and therefore require any changes in the cache may clear a connections
cache before a pipeline that does need said change has an opportunity to
add it to the relevant list.
Allow connections to manage their cache directly rather than the source
doing it vicariously ignorant of other pipelines/sources. Collect the
relevant changes from all pipelines and ask any connections holding a
cache for that item to keep it on reconfiguration.
Co-Authored-By: James E. Blair <firstname.lastname@example.org>
Make sure we update the referenced change object on a new gerrit
event rather than waiting to remake the queue item.
This was a performance regression in the connection changes.
This is a large refactor and as small as I could feasibly make it
while keeping the tests working. I'll do the documentation and
touch ups in the next commit to make digesting easier.
and test the all sources adhere to the set contract.
Also standardise the source (triggers to come) class names
This will make it easier to do more sources in the future and also
add the possibility of loading sources dynamically.
Co-Authored-By: Gregory Haynes <email@example.com>
This is to further differentiate between sources and triggers.
Eventually allowing for multiple triggers per pipeline.
Still to come is separating connections from everything.