| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This expands the rest API for zuul for selecting a portion of the zuul
data.
The supported urls are:
- /status: return a complex data structure that represents the entire
queue / pipeline structure of the system
- /status.json (backwards compatibility): same as /status
- /status/change/X,Y: return status just for gerrit change X,Y
In the individual status case the changes are returned as a simple
array, and not in the pipeline structure.
Tests are added to demonstrate this working, as well as ensure 404 is
correctly returned when invalid urls are provided.
Co-Authored-By: Joshua Hesketh <joshua.hesketh@rackspace.com>
Change-Id: Ib8d80530cc99c222226f73046c17ab0bbf6e080b
|
| |/
|
|
|
|
|
| |
Use new location for OpenStack's layout.yaml file.
Change all occcurences of github in the file to use git.openstack.org
Change-Id: I416fe33563e0df32b8d175b5694243550ee9e63a
|
| |
|
|
|
|
|
| |
When creating a merge job, give it the precedence of the associated
pipeline.
Change-Id: I96c6a942a08f603ae7cce442427ae171d7e76d78
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
As per the governance resolution https://review.openstack.org/119875,
projects should have a docs environment in their tox.ini testing
interface. Rename the doc environment to docs.
Change-Id: I5908033d835d35a0650b77b01ff727d81eb79eb0
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Incorrect filter by ref in zuul layout could end on
applying a regex to a None value, causing an error and
zuul crashing. That is not an usual thing but could happen
and zuul crashes because of that.
Add the comparison for ref not being None
before applying the regex, as it was done for comment
comparison.
Change-Id: Ie58bb288a1f7609564283a0062e08ecc45b28cd0
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
On the status page, if a job was queued via a timer or some way
other than a gerrit change id, the git commit id would be too long
for the change box. Limit it to 7 chars.
Co-Authored-By: Sergey Lukjanov <slukjanov@mirantis.com>
Change-Id: I4f54845675d11e4f76240cf4bf7b48f28f3e7d6a
|
| |\ \ \ \
| |/ / / |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If the job name was too long the progress bar would float under the
next job. Fix this be clearing the flots in each job line.
Change-Id: Ie476cd97ee6207fac84051e0580871590bccbc0f
|
| |\ \ \ \
| |/ / / |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The default filter value for the status page was not being set correctly.
As such the filter would incorrectly remove all results. When no cookie
is set, make sure the filter is blank.
Change-Id: I4868db8b357373d1fd94dc6ffc7528692b75dd8d
|
| | |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since keystoneclient pulls in lxml which needs various system
library headers to build its bindings, and swiftclient depends on
keystoneclient, and zuul handles these as optional dependencies,
make them test requirements.
Change-Id: I5c7db10644dcf2810cbfdfe8c11d4790909c04cf
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Clean up the bad layout files in the zuul tests by removing a redundant
file (bad_pipeline and bad_pipeline1.yaml were identical). Annotate the
reason the layout is bad in each file. Finally remove a redundant swift
section. Both bad switf sections were failing for the same reason, a
missing name entry.
Change-Id: I0fd09da1fb0ec7443fa7d12a3b31809546a01afd
|
| |\ \ \ \ |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Clone repos from cache-dir if they exist, then reset their origins
to be the git base url and update from there.
Change-Id: Ic42961aa5da9e4a66524ec14758d421944403f91
|
| |\ \ \ \ \
| |/ / / / |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Add a facility to override the indicated branch for a specific
project. In OpenStack, this is used to specify that tempest should
always use its master branch even though it has stable branches
(we no longer use stable branches for tempest). It may also be
useful in some kinds of compatibility cross-testing.
The test for this is taken from 'test_multi_branch_project_override'
in devstack-gate.
Change-Id: I958af233d1def3b1c7362e1b2ddc77c108766358
|
| |\ \ \ \ \
| |/ / / / |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is the 'test_grenade_forward' and 'test_upgrade_backward'
tests from d-g. Both scenarios are covered because they both
simulate havana->master upgrades, just changing which of them
is the 'current' change. Since we examine the states of all
changes, in the course of running the test we check the results
for both when a current change is havana and master.
This also covers the 'test_branch_override' case from d-g.
Change-Id: I95abd62279bd44e88a608ad908f4876d11d50ec2
|
| |\ \ \ \ \
| |/ / / / |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The cloner takes an argument for the "indicated branch", however,
that argument has a default value of None, rendering it optional.
In the original setup method from devstack gate, that argument
was not optional, instead, it was typically set to ZUUL_BRANCH
unless it needed to be specified otherwise, for example for grenade.
Effectively, if omitted the (optional) branch argument to the cloner
it would use the 'master' branch in preference to the ZUUL_BRANCH
for projects that do not have a zuul ref. This is not the desired
behavior in the simple case (or quite likely any case), and therefore
should not be the default behavior for the cloner.
Resolve this by having the cloner treat the indicated branch as
ZUUL_BRANCH unless it is specified in the branch argument. In doing
this, the logic in the cloner is slightly simplified and now more
closely matches that in the setup_project function in devstack-gate.
Rename the cloner test to 'test_one_branch' to match the pattern from
devstack-gate tests. This test encompases the 'test_one_on_master'
and 'test_two_on_master' tests from d-g. They are combined because
in these tests we are able to iterate over the Zuul builds and check
the state for each build in turn, which is a more complete form of
testing than what was employed in d-g.
Add the 'test_multi_branch' test to the cloner. This encompases
'test_multi_branch_on_master' (with an additional fourth project
with no changes), as well as 'test_multi_branch_on_stable'.
Change-Id: Ib26bced46073bd61298c52c836a20085511201f3
|
| |\ \ \ \ \
| |/ / / / |
|
| | | |_|/
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The cloner test was incorrectly asserting that project2 should
always be at the commit specified for change B. However, when
testing change A, project2's repo should be at master.
The cloner actually works as intended, the reason the assertion
passed is that the cloner was being run _after_ the gate jobs
finished, meaning that the master branch of project2 actually
was the commit specified for change B -- because it had merged.
Correct this by moving the build release to the end of the test,
so that the test operates entirely within the time that the jobs
are building (before anything merges). Change the checks that
the commits are correct so that they assert the different and
correct values for each of the builds being tested.
Additionally, remove some unecessary actions from the test (adding
additional patchsets and specifying a clone map that is not used).
Change-Id: I7575e8b84925115393cef81d6b02a3532913ffed
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The documentation could be read to imply a check, gate, et cetera
pipeline must contain a job, when in fact pipeline definition is optional
in templates.
.
Inform the reader of the documentation as it isn't entirely clear for
folks maintaing projects where the developer is not a zuul developer.
Change-Id: If386e9431d486f8cea2ebde52c555305e1278c7d
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Latest testtools checks that you only call tearDown once (it also checks
that setUp is only called once). Zuul's test framework was calling
tearDown from a cleanup which resulted in tearDown being called twice.
Once by the test framework and once by zuul's testclasses cleanups.
Just remove the explicit tearDown call in the cleanups and let the
larger python tooling call tearDown for us.
Change-Id: Id8eaa9da5153fdfe9b9f852d2c57838736cb7040
|
| |\ \ \ |
|
| | | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I had Zuul Scheduler report warning messages such as:
zuul.Scheduler: Build set <zuul.model.BuildSet object at 0x1a9a310> is
not current
Which is not very meaningful. This adds a __repr__ to BuildSet which
shows up:
- the QueueItem representation
- number of builds in the set
- merge state
The merge states are internally stored using integer constants. I have
duplicated the information in a dict to lookup the int as a meaningful
string. That is not pretty :(
Change-Id: I0e087e4cb3f4c1da4ef40d0805793f737af1765e
|
| |\ \ \
| |_|/
|/| | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
A previous change removed the trigger cache cleanup. When Zuul
is live-reconfigured, it creates new Project objects and
attaches them to all changes currently in pipelines. Because
the cache contained changes outside of pipelines, those changes
were not being updated with new Project objects.
This restores the maintainCache method and uses it during the
reconfigure event to clear the cache of all changes not currently
in pipelines. This corrects the error introduced by the previous
change as well as gives Zuul an opportunity to release unused
memory (as now the cache will at least be emptied on each
reconfiguration).
The project-change-merged test is updated to explicitly test this
situation.
Change-Id: I67736fca08f2e14ab733bd9f143820da19839ef9
|
| | |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Voluptions does a depth first in order traversal of the data structures
it is checking and fails fast. This means it will die when it hits the
first error and return only that error. The test_layouts test is
checking that different bad layout files fail in unique ways. This check
breaks when the python hashseed is random resulting in different depth
first traversals which can result in returning the same error twice if
bad layout files have common errors.
Fix this by trimming down the errors in each layout file to a single
error this way the order of the errors hit never matters.
Fix a string typo in test_layouts while we are in there.
Change-Id: Ie7587ebac4d22063a6819c68011f7fb67a49fcc0
|
| |\ \
| |/
|/| |
|
| | |
| |
| |
| |
| |
| |
| | |
It may have ended up with changes still in the pipeline because
it uses the timer trigger.
Change-Id: Ieb46d7b5b7020e62e7d3baa704e3f75f9f87dca1
|
| |\ \ |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Function updateChange short-cuts dependency checking for merged changes, but
some attributes that need to be updated were after the short-cut return.
This resulted in zuul saying status is MERGED, but then not matching
Changeish filter for status MERGED.
Closes-Bug: 1356662
Change-Id: I954b2716a5af75a959d4129ba88d7dae0750d2a5
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The zuul trigger ends up querying a large number of changes on
each merge, most of which are not in any pipelines. To avoid
needlessly querying gerrit for data that do not change, keep
all changes that Zuul ever sees in the cache.
We could consider removing changes that are both not in pipelines
and closed (ie, keep all open changes), but we still end up querying
a number of merged changes each time due to Zuul following
dependencies of open changes.
Change-Id: Ie78df9aa43ec5ac35bdea79dcdafdfdd41d51d5b
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Against a live gerrit, we observed that sometimes gerrit may not
return data for a change. In the case of the zuul trigger's
project-change-merged event, it's best to just ignore errors
for those changes and proceed.
Also, the gerrit trigger was attempting to parse the timing
results from the query. The test did not catch this because it
did not supply them in the mocked method. Correct this as well.
Also, double check that the query used was the one expected in
the test.
Change-Id: I792127d29f67f53a419eb94e9e0afb83b6e1bcb2
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This adds the ability for a pipelite to have multiple triggers.
This also adds a "Zuul" trigger which is used to generate trigger
events based on internal actions Zuul has taken.
It supports two event types:
* parent-change-enqueued: This can be used so that other pipelines
can enqueue children of parents that are enqueued in a different
pipeline. Specifically, this lets OpenStack enqueue changes in
check when their parents are enqueued in gate (which may be
necessary because of our clean check rules).
This could be used to replace the internal logic that enqueues
children in dependent pipelines (moving that into explicit
configuration instead).
One can also imagine a future 'change-enqueued' event so that a
pipeline could react directly to a change in another.
* project-change-merged: This can be used to trigger changes on all
open changes for a project when a change is merged to that project.
Specifically, this lets us perform light-weight merge checks on all
open changes whenever a change is merged.
Change-Id: I2a67699dbed92a6b9c143a77795cb126f1f4dd57
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A TriggerEvent may originate from a trigger that does not represent
the canonical location of the project source. For instance, the
timer trigger strangely depends on the gerrit trigger to actually
handle Git operations behind the scenes. Instead, make an explicit
association between pipelines and their source triggers so that
their event trigger does not need to have that implicit association.
This is a step toward having pipelines support multiple triggers
(they already support multiple reporters).
Change-Id: Ie80ffde411fe40fddfc4496b7adb0004f660c48c
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I can not use the switclient on my installation and need a way to
prevent the swiftclient import entirely.
The only usage of the swiftclient module is to establish a connection
which only happen if there is a [swift] section in the configuration.
Moving the import from the top of the file next to its only usage would
make sure my installs never has to get swiftclient installed.
Change-Id: Ie2ef84f86f9f57796a85758147ba87d8b22c3e55
|
| |\ \ \
| |/ / |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
To generate the hmac details for the swift FormPost middleware
you do not need to actually connect to swift if you know the
URL key and storage path.
Change the configuration to reflect this and only connect if
required.
Change-Id: Iad5008ca2707ef5310b172fe3b6844e51bee2372
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Gerrit 2.4 did not provide a stream event for draft patchsets therefore it was not
supported in zuul either. We've just upgraded to Gerrit 2.8 which does provide a
new draft-published stream event. This change will make zuul aware of the draft-published
event.
Change-Id: Ica363b4672cfce375d64463636d84e92c2949fd6
Partial-Bug: #1255166
|
