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
do so.
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
cover them.
Change-Id: Ib2f7297d81f7a003de48f799dc1b09e82d4894bc
Expose the ability to refresh a change in zuul/connection/gerrit.py
too, which is needed for our unit testing.
Change-Id: Iefd09d9b8deef563299e0f209d95e25b61aa4c1e
Signed-off-by: Paul Belanger <pabelanger@redhat.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.
Change-Id: I0dfcd61f343a235dcf935aea434b9772d6e746d9
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.
Change-Id: I2dd88e1165267e4f987a205ba55923eaec7ea9ce
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 <jeblair@linux.vnet.ibm.com>
Change-Id: I2bf8ba6b9deda58114db9e9b96985a2a0e2a69cb
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.
Change-Id: I2a967f0347352a7674deb550e34fb94d1d903e89
This begins a lot of related changes refactoring config loading,
the data model, etc., which will continue in subsequent changes.
Change-Id: I2ca52a079a837555c1f668e29d5a2fe0a80c1af5
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.
Change-Id: Iac5083996a183d1d8a9b6cb8f70836f7c39ee910
and test the all sources adhere to the set contract.
Also standardise the source (triggers to come) class names
to NameSource.
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 <greg@greghaynes.net>
Change-Id: I15b32013904f60873601dd7cc8fce3c158787de4
This is to further differentiate between sources and triggers.
Eventually allowing for multiple triggers per pipeline.
Still to come is separating connections from everything.
Change-Id: I1d680dbed5f650165643842af450f16b32ec5ed9
James E. Blair