blob: 0efb195a7d85b73678b5cd4cff3083859f0c1077 [file] [log] [blame]
James E. Blaireff5a9d2017-06-20 00:00:37 -07001:title: Gerrit Driver
2
3Gerrit
4======
5
6`Gerrit`_ is a code review system. The Gerrit driver supports
7sources, triggers, and reporters.
8
9.. _Gerrit: https://www.gerritcodereview.com/
10
11Zuul will need access to a Gerrit user.
12
13Create an SSH keypair for Zuul to use if there isn't one already, and
14create a Gerrit user with that key::
15
16 cat ~/id_rsa.pub | ssh -p29418 review.example.com gerrit create-account --ssh-key - --full-name Zuul zuul
17
18Give that user whatever permissions will be needed on the projects you
19want Zuul to report on. For instance, you may want to grant
20``Verified +/-1`` and ``Submit`` to the user. Additional categories
21or values may be added to Gerrit. Zuul is very flexible and can take
22advantage of those.
23
24Connection Configuration
25------------------------
26
27The supported options in zuul.conf connections are:
28
29**driver=gerrit**
30
31**server**
32 FQDN of Gerrit server.
33 ``server=review.example.com``
34
35**canonical_hostname**
36 The canonical hostname associated with the git repos on the Gerrit
37 server. Defaults to the value of **server**. This is used to
38 identify repos from this connection by name and in preparing repos
James E. Blair4d5dd252017-06-23 21:40:56 +010039 on the filesystem for use by jobs. This only needs to be set in the
40 case where the canonical public location of the git repos is not the
41 same as the Gerrit server and it would be incorrect to refer to
42 those repos in configuration and build scripts using the Gerrit
43 server hostname.
James E. Blaireff5a9d2017-06-20 00:00:37 -070044 ``canonical_hostname=git.example.com``
45
46**port**
47 Optional: Gerrit server port.
48 ``port=29418``
49
50**baseurl**
51 Optional: path to Gerrit web interface. Defaults to ``https://<value
52 of server>/``. ``baseurl=https://review.example.com/review_site/``
53
54**user**
55 User name to use when logging into above server via ssh.
56 ``user=zuul``
57
58**sshkey**
59 Path to SSH key to use when logging into above server.
60 ``sshkey=/home/zuul/.ssh/id_rsa``
61
62**keepalive**
63 Optional: Keepalive timeout, 0 means no keepalive.
64 ``keepalive=60``
65
66Trigger Configuration
67---------------------
68
69Zuul works with standard versions of Gerrit by invoking the ``gerrit
70stream-events`` command over an SSH connection. It also reports back
71to Gerrit using SSH.
72
73If using Gerrit 2.7 or later, make sure the user is a member of a group
74that is granted the ``Stream Events`` permission, otherwise it will not
75be able to invoke the ``gerrit stream-events`` command over SSH.
76
77The supported pipeline trigger options are:
78
79**event**
80The event name from gerrit. Examples: ``patchset-created``,
81``comment-added``, ``ref-updated``. This field is treated as a
82regular expression.
83
84**branch**
85The branch associated with the event. Example: ``master``. This
86field is treated as a regular expression, and multiple branches may
87be listed.
88
89**ref**
90On ref-updated events, the branch parameter is not used, instead the
91ref is provided. Currently Gerrit has the somewhat idiosyncratic
92behavior of specifying bare refs for branch names (e.g., ``master``),
93but full ref names for other kinds of refs (e.g., ``refs/tags/foo``).
94Zuul matches what you put here exactly against what Gerrit
95provides. This field is treated as a regular expression, and
96multiple refs may be listed.
97
98**ignore-deletes**
99When a branch is deleted, a ref-updated event is emitted with a newrev
100of all zeros specified. The ``ignore-deletes`` field is a boolean value
101that describes whether or not these newrevs trigger ref-updated events.
102The default is True, which will not trigger ref-updated events.
103
104**approval**
105This is only used for ``comment-added`` events. It only matches if
106the event has a matching approval associated with it. Example:
107``code-review: 2`` matches a ``+2`` vote on the code review category.
108Multiple approvals may be listed.
109
110**email**
111This is used for any event. It takes a regex applied on the performer
112email, i.e. Gerrit account email address. If you want to specify
113several email filters, you must use a YAML list. Make sure to use non
114greedy matchers and to escapes dots!
115Example: ``email: ^.*?@example\.org$``.
116
117**email_filter** (deprecated)
118A deprecated alternate spelling of *email*. Only one of *email* or
119*email_filter* should be used.
120
121**username**
122This is used for any event. It takes a regex applied on the performer
123username, i.e. Gerrit account name. If you want to specify several
124username filters, you must use a YAML list. Make sure to use non greedy
125matchers and to escapes dots!
126Example: ``username: ^jenkins$``.
127
128**username_filter** (deprecated)
129A deprecated alternate spelling of *username*. Only one of *username* or
130*username_filter* should be used.
131
132**comment**
133This is only used for ``comment-added`` events. It accepts a list of
134regexes that are searched for in the comment string. If any of these
135regexes matches a portion of the comment string the trigger is
136matched. ``comment: retrigger`` will match when comments
137containing 'retrigger' somewhere in the comment text are added to a
138change.
139
140**comment_filter** (deprecated)
141A deprecated alternate spelling of *comment*. Only one of *comment* or
142*comment_filter* should be used.
143
144*require-approval*
145This may be used for any event. It requires that a certain kind
146of approval be present for the current patchset of the change (the
147approval could be added by the event in question). It follows the
148same syntax as the :ref:`"approval" pipeline requirement
149<pipeline-require-approval>`. For each specified criteria there must
150exist a matching approval.
151
152*reject-approval*
153This takes a list of approvals in the same format as
154*require-approval* but will fail to enter the pipeline if there is
155a matching approval.
156
157Reporter Configuration
158----------------------
159
160Zuul works with standard versions of Gerrit by invoking the
161``gerrit`` command over an SSH connection. It reports back to
162Gerrit using SSH.
163
164The dictionary passed to the Gerrit reporter is used for ``gerrit
165review`` arguments, with the boolean value of ``true`` simply
166indicating that the argument should be present without following it
167with a value. For example, ``verified: 1`` becomes ``gerrit review
168--verified 1`` and ``submit: true`` becomes ``gerrit review
169--submit``.
170
171A :ref:`connection<connections>` that uses the gerrit driver must be
172supplied to the trigger.