doc/source/triggers.rst

:title: Triggers

Triggers
========

The process of merging a change starts with proposing a change to be
merged.  Primarily, Zuul supports Gerrit as a triggering system, as
well as a facility for triggering jobs based on a timer.
Zuul's design is modular, so alternate triggering and reporting
systems can be supported.

Gerrit
------

Zuul works with standard versions of Gerrit by invoking the ``gerrit
stream-events`` command over an SSH connection.  It also reports back
to Gerrit using SSH.

Gerrit Configuration
~~~~~~~~~~~~~~~~~~~~

Zuul will need access to a Gerrit user.  Consider naming the user
*Jenkins* so that developers see that feedback from changes is from
Jenkins (Zuul attempts to stay out of the way of developers, most
shouldn't even need to know it's there).

Create an SSH keypair for Zuul to use if there isn't one already, and
create a Gerrit user with that key::

  cat ~/id_rsa.pub | ssh -p29418 gerrit.example.com gerrit create-account --ssh-key - --full-name Jenkins jenkins

Give that user whatever permissions will be needed on the projects you
want Zuul to gate.  For instance, you may want to grant ``Verified
+/-1`` and ``Submit`` to the user.  Additional categories or values may
be added to Gerrit.  Zuul is very flexible and can take advantage of
those.

Zuul References
~~~~~~~~~~~~~~~

As the DependentPipelineManager may combine several changes together
for testing when performing speculative execution, determining exactly
how the workspace should be set up when running a Job can be complex.
To alleviate this problem, Zuul performs merges itself, merging or
cherry-picking changes as required and identifies the result with a
Git reference of the form ``refs/zuul/<branch>/Z<random sha1>``.
Preparing the workspace is then a simple matter of fetching that ref
and checking it out.  The parameters that provide this information are
described in :ref:`launchers`.

These references need to be made available via a Git repository that
is available to Jenkins.  You may accomplish this by either serving
Zuul's git repositories directly, allowing Zuul to push the references
back to Gerrit, or pushing the references to a third location.
Instructions for each of these alternatives are in the following
sections.

Serving Zuul Git Repos
""""""""""""""""""""""

Zuul maintains its own copies of any needed Git repositories in the
directory specified by ``git_dir`` in the ``zuul`` section of
zuul.conf (by default, /var/lib/zuul/git).  If you want to serve
Zuul's Git repositories in order to provide Zuul refs for Jenkins, you
can configure Apache to do so using the following directives::

  SetEnv GIT_PROJECT_ROOT /var/lib/zuul/git
  SetEnv GIT_HTTP_EXPORT_ALL

  AliasMatch ^/p/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$ /var/lib/zuul/git/$1
  AliasMatch ^/p/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/lib/zuul/git/$1
  ScriptAlias /p/ /usr/lib/git-core/git-http-backend/

And set ``push_change_refs`` to ``false`` (the default) in the
``zuul`` section of zuul.conf.

Note that Zuul's Git repositories are not bare, which means they have
a working tree, and are not suitable for public consumption (for
instance, a clone will produce a repository in an unpredictable state
depending on what the state of Zuul's repository is when the clone
happens).  They are, however, suitable for automated systems that
respond to Zuul triggers.

Pushing to Gerrit
"""""""""""""""""

If you want to push Zuul refs back to Gerrit, set the following
permissions for your project (or ``All-Projects``) in Gerrit (where
``CI Tools`` is a group of which the user you created above is a
member)::

    [access "refs/zuul/*"]
            create = group CI Tools
            push = +force CI Tools
            pushMerge = group CI Tools
            forgeAuthor = group CI Tools
    [access "refs/for/refs/zuul/*"]
            pushMerge = group CI Tools

And set the following in ``zuul.conf``:

  [replication]
    url1=ssh://user@review.example.com:29418/

Pushing to Another Location
"""""""""""""""""""""""""""

Simply set one or more destination URLs in the ``replication`` section
of zuul.conf as above.

Timer
-----

A simple timer trigger is available as well.  It supports triggering
jobs in a pipeline based on cron-style time instructions.