As it stands, if multiple pipelines
have timers with the same timespec, they will all respond to
the events generated for all of them.
Instead of matching on the timespec, associate a timer trigger
with a pipeline directly.
Change-Id: I6a799cc3b59bd7527ace9ee1048bf633dcaa4cd9
We want to report on "changes" triggered by a timer. Since those
aren't really changes, they are represented by a class called
NullChange which carries as much of the interface for a Change
object as possible (not much) so that they can be enqueued in
pipelines.
If a NullChange is reportable, then pretty much any kind of
change should be considered reportable. So remove the flag that
indicates that NullChanges and Refs are not reportable.
Only attempt to format a change report if there is an action
defined for that pipeline (in case the default formatting process
attempts to access a change attribute that is inappropriate).
Remove checks that try to avoid formatting or sending a report
based on attributes of the change (which are no longer relevant).
Add a test for using a timer trigger with an smtp reporter.
Add validation of the attributes that an smtp reporter can use in
the layout file.
Allow the operator to configure a Subject for smtp reports.
Change-Id: Icd067a7600c2922a318b9ade11b3946df4e53065
It'll help us to determine whether we're running a version of zuul that has
added support for some new feature.
The version_string() from pbr's version_info used to collect zuul version.
Change-Id: Id451f15538258ab2dec8e3e8f000cff4a8b7b20d
Provide the short name of a project (anything after the last '/') to
project templates as the variable 'name'. If 'openstack/nova' invoked
a template, the variable 'name' would automatically be set to 'nova'
within the template.
Ideally this means that most template invocations in OpenStack's layout
will not need any variables defined.
Change-Id: I596744917c30c92041b8ea5b1f518d50fb64e59b
Accept multiple template invocations per project, and also allow
adding individual jobs to a project that uses templates.
Change-Id: I6c668dd434c12bec96b9a27afd9fd2eca7a11d0a
Takes one or more changes and promotes them to the head of the queue.
Also, change the command line syntax for the enqueue command to accept
change IDs in the form 'change,patchset' in order to match the syntax
of promote, as well as be potentially more compatible with future
triggers.
Change-Id: Ic7ded9587c68217c060328bf4c3518e32fe659e3
Create a new management event queue to handle external requests
for actions that are not related to triggers or results.
Use this for reconfiguration events. Subsequent patches will use
it for other kinds of events.
Change-Id: Ia018d9a7acc35aaf615ca85f75c9f4c630a5287f
Adds programoutput sphinx extension as a test dependency so doc
builds can include the program help text.
Change-Id: Iec2f09f710162614cbb393a5628204ddebe2e29f
When combining change queues, given 3 projects that were transitively
connected by shared jobs, depending on the order of processing, it
was possible for them not to be combined. To correct this, repeat
the combining operation until the resulting set can be combined no
further.
In order to make the test (and actual usage) behavior more deterministic,
the list of projects returned by the pipeline is now sorted by name.
A test is added for this.
Change-Id: If1386cad4118257efee9aa9918ad12a626927038
Add a command line client called 'zuul' that supports one command
to start with: 'enqueue'. It allows an operator (one with access
to the gearman server) to enqueue an arbitrary change in a specified
pipeline. It uses gearman to communicate with the Zuul server, which
now has an added RPC listener component to answer such requests via
gearman.
Add tests for the client RPC interface.
Raise an exception if a Gerrit query does not produce a change. Unlike
events from Gerrit, user (or admin) submitted events over the RPC bus
are more likely to reference invalid changes. To validate those, the
Gerrit trigger will raise an exception (and remove from its cache) changes
which prove to be invalid.
Change-Id: Ife07683a736c15f4db44a0f9881f3f71b78716b2
This patch adds the zuul_url option in zuul conf file
in order to pass ZUUL_URL to Jenkins, which will be used
by devstack-vm-gate-wrap.sh.
Documentation added in launchers.rst and zuul.rst
explaining how this new option works.
Change-Id: I840423cc06fdfdacd301d30be3e0b3e589e563e9
* zuul/merger.py: Zuul's merger.Repo is holding on to repo objects that
keep many file descriptors open. Turn all git.Repo objects into method
local references so that the git.Repo objects can be garbage collected
once these methods are popped off the stack. GCing these objects frees
the file descriptors associated with that repo. This adds overhead to
repo operations as each operation must do initial setup IO.
* tests/test_scheduler.py: Assert that no instances of git.Repo are
known to the python garbage collector. Do the assertion after running a
fully garbage collection run. This is a cheap check that repo objects
are being garbage collected properly at the end of each test.
Change-Id: I1d67981f32708a85af62ca622402de9fac0e1842
* zuul/merger.py: Previously zuul's merger only checked an initialized
flag to determine if a repo should be cloned. If the state of the disk
changes under zuul the repo may need to be recloned even if the
initialized flag is set. Check if the repo exists on disk to determine
if the repo should be cloned to deal with external state changes. Keep
initialized flag in order to preserve ability to change git repo
settings for user and email.
* tests/test_scheduler.py: Add a test that checks a repo is recloned
when removed from the filesystem under zuul.
* tests/fixtures/layout-repo-deleted.yaml: Layout fixture for new test
added above. This creates a new repo unused by any other tests so that
failures of this test do not interfere with other tests, they will run
independent of each other.
Change-Id: I14fb34a2916002cefef73e41ec9182a073d59ef3
ASCII art is fun but not savvy for project managers and directors. This
patch slightly enhance the 'gating' documentation with colored diagrams.
This is made possible via http://blockdiag.com/ by Takeshi KOMIYA who
even took the time to write a sphinx extension. The version dependency
is at the very least 0.5.5, but might be higher :/
Change-Id: Ibe3c2674a5dff2114c40a84ffdec8a8886b1b21b
When doing the layout validation, I ended up spammed with a few errors:
ERROR:zuul.Scheduler:Invalid reporter name gerrit
The issue is that my pipelines use 'gerrit' as reporter while it is not
registered when testing the config. I registered the 'smtp' reporter as
well and the error is gone.
Side effect: the layout validation output now dumps actions for
start/success/failure.
Change-Id: I271a2943fa3e846ae60d9b615cd3a1ac3815bb1b
Voluptuous 0.7.0 introduced a backward API incompatible change in
upstream commit 475adebc:
https://github.com/alecthomas/voluptuous/commit/475adebc
The schema are precompiled and the validate_X have been removed,
voluptuous is now smart enough to detect the type of value being
validated and would call an internal validation method matching the
type.
Commit is contained since 0.7.0:
$ git tag --contains 475adebc
0.7.0
0.7.1
0.7.2
0.8.1
0.8.2
$
I tested it using etc/layout.yaml-sample and added an inexistent
pipeline to the project. The test yield:
voluptuous.MultipleInvalid: extra keys not allowed @
data['projects'][0]['nonpipe']
Debian has recently accepted voluptuous 0.8.2 in testing, so if we want
to package Zuul, we better have to upgrade our voluptuous requirement as
well. Ref: http://packages.qa.debian.org/v/voluptuous.html
Change-Id: I117ea644863b2e4a4dc3429aa81e868573382877
The intersphinx extensions let one reserve a link namespace and map it
to a remote URL, for example to refer to the Python documentation. A
drawback is that, from time to time, Sphinx will attempt to download an
object inventory from the remote, that is not convenient when running
sphinx in offline mode such as in a plane.
Change-Id: Idef8e88545715a3f1cb9ace002960a7ad3e37b69
* tools/trigger-job.py: Add a logpath arg and make it required. This
allows us to upload logs to appropriate dirs even when manually
triggering jobs.
Change-Id: I59144a2d5443fb6396af45f302f67bc8eec70780
Previously if a job was listed more than once for a project, it was
ignored. That's pretty arbitrary (it silently dropped the second
without an error; and if there are two, which is the right one
anyway?). OTOH, it's potentially useful to run a job more than
once in order to increase the chance of encountering
notdeterministic behavior. And if listing a job twice is an error,
it is now more likely to be noticed by the operator.
This removes the check for duplicate invocations of a job.
Change-Id: If8e2e8cc3fca855bd6b14eb3a957dadddfe143ed
So that the status display and logs read more better.
Also, include the Zuul ref in JSON output so that the status
screen can do something intelligent with unprocessed items (also
it's an important bit of into).
Change-Id: I1429344917856edfaeefa4e9655c2dad8081cae5
The launcher documentation about 'Starting Builds' evokes the
parameter-function in the zuul.conf documentation. One had to goes down
a few pages until the 'Includes' subsection. I have updated the
references to point directly to Includes, saving the reader sometime.
Also fixed a typo: paremeter -> parameter
Change-Id: I560f857b40a7cb989a71161f94e1fb0c8fd69293
Where we're using the same libraries as OpenStack, sync with the
OpenStack versions. Just to be nice.
Change-Id: I8e90d2a8945d62e962b813c6396f0e7db4e14222
d2to1 pulls in setuptools, which trips the unhappy bugs with setuptools
updating. Move past that and just use new pbr.
Change-Id: I2609eda10ed781116940c3607ff85a14fc4b7f58
Jenkins
James E. Blair
Sergey Lukjanov
Paul Belanger
Arx Cruz
Clark Boylan
Antoine Musso
Michael Prokop
Monty Taylor