1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
|
:title: GitLab Driver
.. _gitlab_driver:
GitLab
======
The GitLab driver supports sources, triggers, and reporters. It can
interact with the public GitLab.com service as well as site-local
installations of GitLab.
Configure GitLab
----------------
Zuul needs to interact with projects by:
- receiving events via web-hooks
- performing actions via the API
web-hooks
^^^^^^^^^
Projects to be integrated with Zuul needs to send events using webhooks.
This can be enabled at Group level or Project level in "Settings/Webhooks"
- "URL" set to
``http://<zuul-web>/api/connection/<conn-name>/payload``
- "Merge request events" set to "on"
- "Push events" set to "on"
- "Tag push events" set to "on"
- "Comments" set to "on"
- Define a "Secret Token"
API
^^^
| Even though bot users exist: https://docs.gitlab.com/ce/user/project/settings/project_access_tokens.html#project-bot-users
| They are only available at project level.
In order to manage multiple projects using a single connection, Zuul needs a
global access to projects, which can only be achieved by creating a specific
Zuul user. This user counts as a licensed seat.
The API token must be created in user Settings, Access tokens. The Zuul user's
API token configured in zuul.conf must have the following ACL rights: "api".
Connection Configuration
------------------------
The supported options in ``zuul.conf`` connections are:
.. attr:: <gitlab connection>
.. attr:: driver
:required:
.. value:: gitlab
The connection must set ``driver=gitlab`` for GitLab connections.
.. attr:: api_token_name
The user's personal access token name (Used if **cloneurl** is http(s))
Set this parameter if authentication to clone projects is required
.. attr:: api_token
The user's personal access token
.. attr:: webhook_token
The webhook secret token.
.. attr:: server
:default: gitlab.com
Hostname of the GitLab server.
.. attr:: canonical_hostname
The canonical hostname associated with the git repos on the
GitLab server. Defaults to the value of :attr:`<gitlab
connection>.server`. This is used to identify projects from
this connection by name and in preparing repos on the filesystem
for use by jobs. Note that Zuul will still only communicate
with the GitLab server identified by **server**; this option is
useful if users customarily use a different hostname to clone or
pull git repos so that when Zuul places them in the job's
working directory, they appear under this directory name.
.. attr:: baseurl
:default: https://{server}
Path to the GitLab web and API interface.
.. attr:: sshkey
Path to SSH key to use (Used if **cloneurl** is ssh)
.. attr:: cloneurl
:default: {baseurl}
Omit to clone using http(s) or set to ``ssh://git@{server}``.
If **api_token_name** is set and **cloneurl** is either omitted or is
set without credentials, **cloneurl** will be modified to use credentials
as this: ``http(s)://<api_token_name>:<api_token>@<server>``.
If **cloneurl** is defined with credentials, it will be used as is,
without modification from the driver.
.. attr:: keepalive
:default: 60
TCP connection keepalive timeout; ``0`` disables.
.. attr:: disable_connection_pool
:default: false
Connection pooling improves performance and resource usage under
normal circumstances, but in adverse network conditions it can
be problematic. Set this to ``true`` to disable.
Trigger Configuration
---------------------
GitLab webhook events can be configured as triggers.
A connection name with the GitLab driver can take multiple events with
the following options.
.. attr:: pipeline.trigger.<gitlab source>
The dictionary passed to the GitLab pipeline ``trigger`` attribute
supports the following attributes:
.. attr:: event
:required:
The event from GitLab. Supported events are:
.. value:: gl_merge_request
.. value:: gl_push
.. attr:: action
A :value:`pipeline.trigger.<gitlab source>.event.gl_merge_request`
event will have associated action(s) to trigger from. The
supported actions are:
.. value:: opened
Merge request opened.
.. value:: changed
Merge request synchronized.
.. value:: merged
Merge request merged.
.. value:: comment
Comment added to merge request.
.. value:: approved
Merge request approved.
.. value:: unapproved
Merge request unapproved.
.. value:: labeled
Merge request labeled.
.. attr:: comment
This is only used for ``gl_merge_request`` and ``comment`` actions. It
accepts a list of regexes that are searched for in the comment
string. If any of these regexes matches a portion of the comment
string the trigger is matched. ``comment: retrigger`` will
match when comments containing 'retrigger' somewhere in the
comment text are added to a merge request.
.. attr:: labels
This is only used for ``gl_merge_request`` and ``labeled``
actions. It accepts a string or a list of strings that are that
must have been added for the event to match.
.. attr:: unlabels
This is only used for ``gl_merge_request`` and ``labeled``
actions. It accepts a string or a list of strings that are that
must have been removed for the event to match.
.. attr:: ref
This is only used for ``gl_push`` events. This field is treated as
a regular expression and multiple refs may be listed. GitLab
always sends full ref name, eg. ``refs/heads/bar`` and this
string is matched against the regular expression.
Reporter Configuration
----------------------
Zuul reports back to GitLab via the API. Available reports include a Merge Request
comment containing the build results. Status name, description, and context
is taken from the pipeline.
.. attr:: pipeline.<reporter>.<gitlab source>
To report to GitLab, the dictionaries passed to any of the pipeline
:ref:`reporter<reporters>` attributes support the following
attributes:
.. attr:: comment
:default: true
Boolean value that determines if the reporter should add a
comment to the pipeline status to the GitLab Merge Request.
.. attr:: approval
Bolean value that determines whether to report *approve* or *unapprove*
into the merge request approval system. To set an approval the Zuul user
must be a *Developer* or *Maintainer* project's member. If not set approval
won't be reported.
.. attr:: merge
:default: false
Boolean value that determines if the reporter should merge the
Merge Request. To merge a Merge Request the Zuul user must be a *Developer* or
*Maintainer* project's member. In case of *developer*, the *Allowed to merge*
setting in *protected branches* must be set to *Developers + Maintainers*.
.. attr:: label
A string or list of strings, each representing a label name
which should be added to the merge request.
.. attr:: unlabel
A string or list of strings, each representing a label name
which should be removed from the merge request.
Requirements Configuration
--------------------------
As described in :attr:`pipeline.require` pipelines may specify that items meet
certain conditions in order to be enqueued into the pipeline. These conditions
vary according to the source of the project in question.
.. code-block:: yaml
pipeline:
require:
gitlab:
open: true
This indicates that changes originating from the GitLab connection must be
in the *opened* state (not merged yet).
.. attr:: pipeline.require.<gitlab source>
The dictionary passed to the GitLab pipeline `require` attribute
supports the following attributes:
.. attr:: open
A boolean value (``true`` or ``false``) that indicates whether
the Merge Request must be open in order to be enqueued.
.. attr:: merged
A boolean value (``true`` or ``false``) that indicates whether
the Merge Request must be merged or not in order to be enqueued.
.. attr:: approved
A boolean value (``true`` or ``false``) that indicates whether
the Merge Request must be approved or not in order to be enqueued.
.. attr:: labels
A list of labels a Merge Request must have in order to be enqueued.
Reference pipelines configuration
---------------------------------
Here is an example of standard pipelines you may want to define:
.. literalinclude:: /examples/pipelines/gitlab-reference-pipelines.yaml
:language: yaml
|