Previously the change_ahead for the change_behind was set to None,
but then change_behind was not set to None as well. To properly
delete a change set both pointers to None.
Change-Id: If6d86759d3c10e88fca6e5f977456efd70bd0c32
Jobs for changes weren't being launched for DependentQueueManagers
because its addChange method called the superclass's addChange,
which had the same duplicate suppresion logic. This breaks
out the bulk of that into a private method that can be called
by both classes.
Change-Id: Ib47be82f255bab38ce03c7af7fb5b700e1956aaa
Jobs behind a failed change will need to be rerun so cancel them
to free up resources at the front of the change queue. When a change
at the front of the queue fails it is dequeued and all the jobs behind
it are rerun. When a change in the middle of the queue fails all the
jobs behind it are cancelled. Then the jobs will be rerun when a
change at the front of the queue is dequeued for failure (which may
end up being the change that caused the initial cancellation, or it
may be a change further up in the queue).
Change-Id: Ic0ebe15ec1a8d3a21ff04a6769243729683807ed
By setting 'hold-following-changes' to True on .*-merge jobs,
jobs for following changes in the dependend change queue won't be
launched until all of the -merge jobs ahead of them complete
successfully. This prevents wasting resources on testing changes
that have no chance of merging as tested. It gives up a small
amount of parallelization in order to achieve this (merge jobs will
now run in series, while other jobs may continue to run in parallel).
This should also help ensure that jobs nearer the front of the queue
run sooner than jobs at the back. Currently, the nondeterminism of
job run-time can cause Jenkins to use limited resources on the back
of the queue instead of the front.
Also fixes these bugs:
* The success/failure messages specified were not being used.
* If a parameter function was applied to a meta-job, it would not
be applied to jobs that matched the meta-job.
Change-Id: I03cc3e25c554d8aeb1ddb478afaed168a961962f
If A is a dependent change of B, and A and B finish test around
the same time, the following may happen:
Complete event for A is received.
A is marked as complete.
Complete event for B is received.
B is marked as complete.
Begin processing complete event for A
A is reported.
Since A merged, and B is dependent on A, zuul checks to see if
B should be reported (it may have been waiting on A).
B is complete, so it is reported.
End of processing A's complete event
Begin processing B's complete event
B is reported (but fails to report correctly).
To avoid this, record that a change has been succesfully reported,
(regardless of the outcome of tests), and if requested to report
the change again, simply return True, indicating that it has been
succesfully reported.
Change-Id: I5edbf158e7ef749cf855cadbacdc44161c054c59
A build was recently marked as lost because zuul said it finished
more than 5 minutes ago, but it had not yet finished. This should
give us the information needed to debug that situation.
Change-Id: I2ab95c8110f4c3adf85db999cb6153db89b1b1b2
Add a parameter-function attribute to jobs that specifies a function
that should be called to manipulate parameters passed to jenkins
before a job is launched.
Add the ability to include a python file to define such a function.
Finish implementing the "branch" attribute of jobs that lets you
specify whether a job should run on a particular branch.
Change-Id: I3f4d21ad5ac58a24d44a9a8437daa5c668967db9
A SIGUSR1 will cause zuul to queue new events, wait for existing
jobs to finish, then save the queue and exit.
It will likely take quite a while to complete (perhaps an hour),
so it's not implemented as a SIGTERM handler.
Can be used in an init script to implement a graceful restart.
Change-Id: I09fce571e971f16b5d20c5d69d595a05c7f6a4ba
Preparing for leaving informative messages on build descriptions.
I'd like to be able to leave descriptions that include all the
builds that happened in conjunction with any given build. But
Zuul forgets about completed builds very quickly, so we may not
have all the information when needed. This adds build sets,
which keep track of all the builds that happened at once.
This makes some of our recent status output changes a little
easier/cleaner as well.
This also adds the jenkins method to set a build description,
which is unused in this change, but will be in a follow-on.
Change-Id: I78936dc9284ef0a88272ffdef962718b20485ec7
We were logging the change instead of the build in the debug
log messages while waiting for reconfiguration.
Change-Id: Ib0976901e3c55f78cc7f2d59612f1a0632a17e93
Zuul layouts can now specify that jobs get run when comments match
a filter. Trigger layouts would look like:
trigger:
- event: comment-added
comment_filter:
- reverify
- recheck
This would trigger a job whenever comments containing the string
"reverify" or "recheck" are added to a change.
Change-Id: I3dd75abbf75686b3929dd2bb412b02740911d6ee
The links to Jenkins job pages on the /zuul/status page are awesome,
but now we need links to go the other direction and link back to
Gerrit. Add links using the event['change']['url'] parameter as the
target.
Change-Id: I24f189fd0d14e59e0ae5484b15ea6e3aa899e62f
Some events lack approvals (just a text review, for instance).
Make sure that we set approvals to [] rather than None in that
case to avoid problems in the event matching code which assumes
it is always a list.
Change-Id: I2cd95e3dd0a6254ed3ddaee320cf3316487cea32
If Jenkins starts 404ing a build url, this handles that. Transient
errors should be ignored, persistent errors will declare the build
lost.
Change-Id: I89277df72ed1f4c32c56de767515ab8b14560d4a
Add the ability to specify a report to gerrit on start. This
can be used to clear the verified column.
Fixes bug #1012730.
Change-Id: I8dd2a60c3a16a8fa0046675437c750948af99577
Use __repr__ for more objects so they look better in log messages.
Fix a problem with erroneous information on the "depends on" log
message. Fixes bug #1011908.
Change-Id: I43adc5fd0943d99dae28276b7a72009ce9f9a91c
If Jenkins fails to launch a job, a change can get stuck in the
queue. This is very similar to when we lose track of a build in
Jenkins, so in this case, pretend the build was launched, and mark
it as LOST. The queue will eventually drop the change and things
will keep moving.
Also, Jenkins sometimes erroneously reports 404 on the build URL.
If we get an error launching a job, just retry it for 30 seconds
before we finally give up.
Fixes bug #1011907.
Change-Id: I605fe37abf2fc3e7685df0f7a8e460b9a5d508b3
If an event matches a queue, but is for a project that is
unknown by the queue (but otherwise known), don't do anything
with that event in that queue.
Change-Id: I1f0d9ebcd6539cdbdaba905415765bf779814d03
On maven jobs, a result is reported as soon as one target finishes.
Switch to using 'building' to determine whether a build has
finished, rather than checking for a result.
Change-Id: Ic681d88e77abe6af6af59689337586b48af62d80
If a job is named with a regex starting with ^, treat it as a
meta-job and apply its attributes to matching jobs.
Explicitly set attributes on normal job definitions will override
those set by a meta job.
This should reduce the need to copy/paste error messages for
some common jobs.
Change-Id: I4362f4892d1c60514fbaa9092ecd8b44493c7421
It's okay if an individual queue manager can't find a build, but
we care if _no_ queue managers find the build.
Change-Id: If2470a8bda5316563f92980d631b96037ec76c0f
When SIGHUP is received, trigger events are queued only,
we wait for all builds to complete, re-load the configuration,
then continue.
Initial configuration is now performed the same way, to
make sure it gets exercised.
Change-Id: I41198b6dc9f176c8e57cd4a10ad00e4b7480e1d1
Jenkins
Clark Boylan
Zhongyue Luo
James E. Blair