Use six.moves.urllib.parse instead of urlparse

To keep Python 3.x compatibility, use six.moves.urllib.parse
to replace urlparse.

Add six as a dependency in test_requirements.txt

Change-Id: Ia6cd042970c2d4e5d418a39e25bab32b4d93c544
Minor fixes to styling and coherency

Adds missing periods in item descriptions to bring in line with
the rest of the documentation. Also fixes some typos and styling.

Change-Id: I11ef0bf3f89ecf5f09bb5781cced9b655c71bc65
Fix ZUUL_COMMIT in certain conditions

In a dependent pipeline with changes to multiple branches of
a single project, ZUUL_COMMIT would sometimes point to a commit
further back in the series rather than the commit that should
be tested (ie, not the commit pointed to by ZUUL_REF).  It's
possible this situation could appear in other circumstances as
well.

The error was the re-use of a variable when creating Zuul refs
for the entire series.  The variable should have been reserved
to indicate the final commit but instead could end up containing
the most recent commit of another branch or even project.

A test case is updated to detect both the condition where the
ZUUL_COMMIT for two different changes are the same, as well as
when ZUUL_REF does not point to ZUUL_COMMIT.

Change-Id: I9074746070edeebdff9f2ef3c1bb00526c21cfee
Add configurable footer-message reports

Currently there is no way to add extra information to the end of a
report sent back by zuul. This adds a 'footer-message' field to the
pipelines allowing operators to leave extra information at the end
of a build result.

This is useful for leaving CI contact and debugging information.

Change-Id: Ieae62e845915fa3997353b6b425e215966a9338c
Merge "Use six.moves.urllib.parse instead of urlparse"
Submitted is _not_ necessarily merged in Gerrit

* zuul/trigger/gerrit.py(Gerrit._isMerged): Only consider MERGED
status to indicate a change is successfully merged. SUBMITTED can
exist on changes which Gerrit was unable to merge due to nonexistent
parent/dependent commits, and possibly for other reasons too.

Change-Id: I673be5010031f8bc26ab31db9afcc7c28854db85
Document the Zuul triggers

Zuul send different sets of parameters depending on the event that
triggered a build, split the parameters in sub sub sections for some
clarity.

Added examples of ref-updated parameters.

Sub-sub section for the jenkins configuration.

Change-Id: I1edcd5c3a101e2afe0025ad4cd3e511582998999
Make zuul-merger default pidfile match init script

The init script for the zuul-merger file does not look for the
zuul-merger PIDFILE in the same default location that the zuul-merger
uses. Make them both look at /var/run/zuul-merger/zuul-merger.pid.

Change-Id: Ia5829ef3887a5651d23a80dbd00e76972c7cf6a7
Merge "Minor fixes to styling and coherency"
Add more logging to zuul merger process

Add logging to the zuul merger process that includes change numbers so
that threads of execution can be easily tracked from the zuul server log
files to the zuul merger log files.

Change-Id: Ic591f3941d6fe84874e16c8309a101a2918979a2
Shut down the gearman server last in tests

In particular, shut it down after all its clients have been shut
down.  In some cases, it was shut down early enough that the RPC
listener was able to attempt to reconnect to it and trigger a
rare condition in gear that would cause the reconnection thread
to hang.

Change-Id: I1dc5d77484eabf9fa43f16ae8295ddb4df4af056
Cancel a build even if not found

Canceling a build is naturally subject to race conditions as the
build is started (since canceling a build is different depending
on whether or not it has started).  This has been handled by
checking whether the build has started, and if so canceling the
build, if not, removing it from the queue, and if that fails,
checking to see if the build just started and if so, canceling
that.

But even that is still racy because it's possible for the build
to have started but for zuul to not have received the gearman
packet indicating that it had.  To handle that, simply don't check
whether the build has started for the third attempt.

(The reason we even check at all before the first attempt is that
canceling a running build in jenkins is somewhat expensive (it
involves iterating over all the builds) so it's better to avoid
that if we think it won't work.)

Also, add an extra check in the unit test suite when deciding
whether the system has settled.  This should deal with the case
that a trigger_event -> job transition is happening during the
haveAllBuildsReported check (which only checks jobs).

Change-Id: I60018a5215e7d8230bdf6ef67ec7bc9c719fc286
Merge "Cancel a build even if not found"
Merge "Shut down the gearman server last in tests"
Merge "Make zuul-merger default pidfile match init script"
Ensure there's always an http server object

It's possible for a test to complete before python gets around to
actually starting the webapp run thread.  Make sure that the
object referenced in the stop method is always instantiated to
avoid "AttributeError: 'WebApp' object has no attribute 'server'"
errors.

Also, mark the webapp thread as daemon on general principle.

Change-Id: I9b4c0c20a98d5429c299748178e31baf8b6912d9
Merge "Fix ZUUL_COMMIT in certain conditions"
Merge "Document the Zuul triggers"
Merge "Add configurable footer-message reports"
Merge "Add more logging to zuul merger process"