James E. Blair | cdd0007 | 2012-06-08 19:17:28 -0700 | [diff] [blame] | 1 | :title: Triggers |
| 2 | |
| 3 | Triggers |
| 4 | ======== |
| 5 | |
| 6 | The process of merging a change starts with proposing a change to be |
James E. Blair | 63bb0ef | 2013-07-29 17:14:51 -0700 | [diff] [blame] | 7 | merged. Primarily, Zuul supports Gerrit as a triggering system, as |
| 8 | well as a facility for triggering jobs based on a timer. |
James E. Blair | cdd0007 | 2012-06-08 19:17:28 -0700 | [diff] [blame] | 9 | Zuul's design is modular, so alternate triggering and reporting |
James E. Blair | 63bb0ef | 2013-07-29 17:14:51 -0700 | [diff] [blame] | 10 | systems can be supported. |
James E. Blair | cdd0007 | 2012-06-08 19:17:28 -0700 | [diff] [blame] | 11 | |
| 12 | Gerrit |
| 13 | ------ |
| 14 | |
| 15 | Zuul works with standard versions of Gerrit by invoking the ``gerrit |
| 16 | stream-events`` command over an SSH connection. It also reports back |
| 17 | to Gerrit using SSH. |
| 18 | |
| 19 | Gerrit Configuration |
| 20 | ~~~~~~~~~~~~~~~~~~~~ |
| 21 | |
| 22 | Zuul will need access to a Gerrit user. Consider naming the user |
| 23 | *Jenkins* so that developers see that feedback from changes is from |
| 24 | Jenkins (Zuul attempts to stay out of the way of developers, most |
| 25 | shouldn't even need to know it's there). |
| 26 | |
| 27 | Create an SSH keypair for Zuul to use if there isn't one already, and |
| 28 | create a Gerrit user with that key:: |
| 29 | |
| 30 | cat ~/id_rsa.pub | ssh -p29418 gerrit.example.com gerrit create-account --ssh-key - --full-name Jenkins jenkins |
| 31 | |
| 32 | Give that user whatever permissions will be needed on the projects you |
| 33 | want Zuul to gate. For instance, you may want to grant ``Verified |
| 34 | +/-1`` and ``Submit`` to the user. Additional categories or values may |
| 35 | be added to Gerrit. Zuul is very flexible and can take advantage of |
| 36 | those. |
James E. Blair | 172c076 | 2012-10-02 15:35:54 -0700 | [diff] [blame] | 37 | |
| 38 | Zuul References |
| 39 | ~~~~~~~~~~~~~~~ |
| 40 | |
| 41 | As the DependentPipelineManager may combine several changes together |
| 42 | for testing when performing speculative execution, determining exactly |
| 43 | how the workspace should be set up when running a Job can be complex. |
| 44 | To alleviate this problem, Zuul performs merges itself, merging or |
| 45 | cherry-picking changes as required and identifies the result with a |
| 46 | Git reference of the form ``refs/zuul/<branch>/Z<random sha1>``. |
| 47 | Preparing the workspace is then a simple matter of fetching that ref |
| 48 | and checking it out. The parameters that provide this information are |
| 49 | described in :ref:`launchers`. |
| 50 | |
| 51 | These references need to be made available via a Git repository that |
| 52 | is available to Jenkins. You may accomplish this by either allowing |
| 53 | Zuul to push the references back to Gerrit, in which case you may |
| 54 | simply use the Gerrit Git repository. If you do not have access to |
| 55 | the Gerrit repository, or would prefer Zuul not push its refs there, |
| 56 | you may directly serve the Git repositories that Zuul uses, and |
| 57 | configure Jenkins to use those. Instructions for each of these |
| 58 | alternatives are in the following sections. |
| 59 | |
| 60 | Pushing to Gerrit |
| 61 | """"""""""""""""" |
| 62 | |
| 63 | If you want to push Zuul refs back to Gerrit, set the following |
| 64 | permissions for your project (or ``All-Projects``) in Gerrit (where |
| 65 | ``CI Tools`` is a group of which the user you created above is a |
| 66 | member):: |
| 67 | |
| 68 | [access "refs/zuul/*"] |
| 69 | create = group CI Tools |
| 70 | push = +force CI Tools |
| 71 | pushMerge = group CI Tools |
| 72 | [access "refs/for/refs/zuul/*"] |
| 73 | pushMerge = group CI Tools |
| 74 | |
| 75 | And set ``push_change_refs`` to ``true`` in the ``zuul`` section of |
| 76 | zuul.conf. |
| 77 | |
| 78 | Serving Zuul Git Repos |
| 79 | """""""""""""""""""""" |
| 80 | |
| 81 | Zuul maintains its own copies of any needed Git repositories in the |
| 82 | directory specified by ``git_dir`` in the ``zuul`` section of |
| 83 | zuul.conf (by default, /var/lib/zuul/git). If you want to serve |
| 84 | Zuul's Git repositories in order to provide Zuul refs for Jenkins, you |
| 85 | can configure Apache to do so using the following directives:: |
| 86 | |
| 87 | SetEnv GIT_PROJECT_ROOT /var/lib/zuul/git |
| 88 | SetEnv GIT_HTTP_EXPORT_ALL |
| 89 | |
| 90 | AliasMatch ^/p/(.*/objects/[0-9a-f]{2}/[0-9a-f]{38})$ /var/lib/zuul/git/$1 |
| 91 | AliasMatch ^/p/(.*/objects/pack/pack-[0-9a-f]{40}.(pack|idx))$ /var/lib/zuul/git/$1 |
| 92 | ScriptAlias /p/ /usr/lib/git-core/git-http-backend/ |
| 93 | |
| 94 | And set ``push_change_refs`` to ``false`` (the default) in the |
| 95 | ``zuul`` section of zuul.conf. |
| 96 | |
| 97 | Note that Zuul's Git repositories are not bare, which means they have |
| 98 | a working tree, and are not suitable for public consumption (for |
| 99 | instance, a clone will produce a repository in an unpredictable state |
| 100 | depending on what the state of Zuul's repository is when the clone |
| 101 | happens). They are, however, suitable for automated systems that |
| 102 | respond to Zuul triggers. |
James E. Blair | 63bb0ef | 2013-07-29 17:14:51 -0700 | [diff] [blame] | 103 | |
| 104 | Timer |
| 105 | ----- |
| 106 | |
| 107 | A simple timer trigger is available as well. It supports triggering |
| 108 | jobs in a pipeline based on cron-style time instructions. |