forked from gera/gitzilla
-
Notifications
You must be signed in to change notification settings - Fork 0
/
README
317 lines (203 loc) · 9.32 KB
/
README
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
304
305
306
307
308
309
310
311
312
313
314
315
316
========
GitZilla
========
GitZilla is Python magic to support Git-Bugzilla integration. There are
various ways of using GitZilla.
Note that GitZilla must be installed on the machine receiving commits from
everyone - home to the the "official" or the "central" repository.
There's a mailing list for GitZilla now, at [email protected]
Summary of features
...................
GitZilla might be the right tool if you want to::
- Automatically add commits to bugs referenced in the commit messages
whenever changes are pushed to a central git repository.
- Reject commits without a bug reference.
- Only allow commits referring to active bugs (reject commits referring to
CLOSED, RESOLVED or any other specific bug states).
- (contributed, untested): Usable with Gerrit.
- Some combination or all of the above.
With the above capabilities, GitZilla allows for::
- Per-user, or system-wide authentication for Bugzilla.
- Configurable bug comment formats and content.
- Optional diffstat as part of the bug comments.
- Configurable regexes for matching bug IDs in commit messages.
Usage
.....
Simple ready scripts
--------------------
To quickly start using GitZilla:
* Install GitZilla. You may choose the .deb for easy installation on
Debian/Ubuntu systems. Otherwise, just unpack the source and install in
the usual setuptools way::
sudo python setup.py install
* Switch to the hooks directory (/path/to/repository/.git/hooks) and delete
the ``post-receive`` and ``update`` hooks.
* Link (or copy) the gitzilla provided hooks::
ln -s $(which gitzilla-post-receive) post-receive
ln -s $(which gitzilla-update) update
* Read and edit the config file at /etc/gitzillarc. A simple (and sufficient
for most cases) configuration is something like::
[/path/to/repository/.git]
bugzilla_url: https://repo.example.com/bugzilla/
bugzilla_user: [email protected]
bugzilla_password: blahblah
allowed_bug_states: NEW, ASSIGNED, REOPENED
(and even the last item is optional!)
* Commit away!
Custom GitZilla
---------------
If you need the hooks to do other stuff apart from just the Bugzilla
integration, you could write your hook as a Python script and leave the
Bugzilla stuff to functions from ``gitzilla.hookscripts`` or
``gitzilla.hooks``.
In fact with the defaults, are equivalent to the following:
post-receive::
#!/usr/bin/python
from gitzilla.hookscripts import post_receive
post_receive()
update::
#!/usr/bin/python
from gitzilla.hookscripts import update
update()
The functions from ``gitzilla.hookscripts`` parse and pick up values from the
configuration files. If you want to taylor more use the functions from
``gitzilla.hooks``.
post-receive::
#!/usr/bin/python
from gitzilla.hooks import post_receive
post_receive("https://repo.example.com/bugzilla", "username", "password")
update::
#!/usr/bin/python
from gitzilla.hooks import update
update("https://repo.example.com/bugzilla", "username", "password")
You could pass a custom bug id extraction regex and your own logging.Logger
instance. The update hook function also accepts an array of allowed bug status
strings.
Look at the module help for gitzilla.hooks for more information.
Down and dirty
--------------
This is an internal-only mode for now. More info when this is stable.
Configuration
.............
GitZilla uses a global configuration file (at /etc/gitzillarc) as well as
per-user configuration files (at ~/.gitzillarc). All the configuration options
are picked up from the global config file, and the user specific config is
allowed to override **only** the ``bugzilla_user`` and ``bugzilla_password``
parameters.
The configuration files themselves are in the ConfigParser format (see
http://docs.python.org/library/configparser.html). A sample configuration
looks like::
[DEFAULT]
user_config: deny
allowed_bug_states: NEW, ASSIGNED, REOPENED
[/path/to/repository/.git]
bugzilla_url: https://repo.example.com/bugzilla/
bugzilla_user: [email protected]
bugzilla_password: blahblah
logfile: /var/log/gitzilla.log
loglevel: info
Each git repository on the system MAY have its own section. The global config
MUST specify the ``bugzilla_url`` parameter.
Default values (applied to each repository unless overridden) may be specified
in a [DEFAULT] section.
The user specific files are entirely optional.
Mandatory parameters
--------------------
- bugzilla_url
Optional parameters
-------------------
- bugzilla_user
the default username for Bugzilla.
- bugzilla_password
the default password for Bugzilla.
- user_config
allow/deny user specific bugzilla credentials. The legal values are
``allow``, ``deny`` and ``force``. Defaults to ``allow``.
- require_bug_ref
if True, the update hook will require that each commit message contains
a bug number. If False, it will not. Defaults to True (same as historical
behaviour).
- allowed_bug_states
a comma separated set of states that a bug must be in, in order for
the commit to be allowed by the update hook.
- formatspec
appended to ``--pretty=format:`` and passed to ``git whatchanged``.
See the ``git whatchanged`` manpage for more info. Newlines are
automatically converted to '%n', which is what the git format spec
requires.
- include_diffstat
include diffstat (a list of changed file with a histogram). If False,
the diffstat is not included. Defaults to True to be consistent with
previous behaviour.
- separator
a string which would never occur in commit messages. You should not
need to set this, as it is already at a safe default.
- bug_regex
the (Python) regex for capturing bug numbers. MUST capture all the
digits (and only the digits) of the bug id in a named group called
``bug``. This regex is compiled internally with the MULTILINE, DOTALL
and IGNORECASE options set. The default regex captures from the
following forms:
* bug 123
* Bug # 123
* BUG123
* bug# 123
* Bug #123
- git_ref_prefix
the string which must start a git reference for its commits to be
processed. Defaults to 'refs/heads/' so that we don't process 'tags/' and
run the risk of processing many commits multiple times. You can set it
to the empty string to process all git references.
- logfile
the file to log to. MUST be writable by the uid of the git process. In
case of ssh pushes, tha usually means it should be writable by all.
- loglevel
can be ``info`` or ``debug``. Defaults to ``debug``.
Security note
-------------
Note that the global config would be readable by all and may contain a bugzilla
credentials. If you think this is a problem, you may rely on per-user auth.
If the ``user_config`` option is set to ``allow`` or ``force``, then auth
credentials are picked up from the user specific ``~/.gitzillarc`` file.
If the ``user_config`` option is ``force`` and the ``~/.gitzillarc`` does not
contain bugzilla credentials, then the ``~/.bugz_cookie`` file is used for
authentication. To generate a cookie file, a user may use the
``gitzilla-gencookie`` script. The cookie validity will of course be dependent
on your Bugzilla configuration. If neither credentials nor the cookie file are
present (and valid), Bugzilla interactions will fail and the commits will be
rejected.
If the ``user_config`` option is ``allow``, then user specific credentials are
used if available. Only if credentials are unavailable in both the
user-specific as well as the systemwide configs, the cookie file is used. This
configuration is the default because of the closeness of behaviour from version
1.0.
To summarize:
- To allow (but not force) users to use their own auth/credentials set
``user_config`` to ``allow`` and set ``bugzilla_user`` and
``bugzilla_password`` in the system wide config.
- To enforce user credentials, set ``user_config`` to ``force`` and leave the
Bugzilla credentials out of the system wide config.
- To use system wide credentials *only*, set ``user_config`` to ``deny``.
- To enforce Bugzilla integration, use the update hook. The update hook will
check the validity of the credentials (system or user, depending on the
config), regardless of the ``allowed_bug_states`` option. This is a change
in behaviour from version 1.0.
Requirements
............
To install and run GitZilla, you need:
- Python (tested with 2.6.4, should work with >=2.5)
- pybugz (tested with 0.8.0)
Of course, to make it useful you also need a Bugzilla installation somewhere
(not required to be on the same machine). GitZilla has been tested with
Bugzilla 3.0.11 and should work with any Bugzilla version supported by pybugz.
The excellent pybugz can be obtained from http://github.com/ColdWind/pybugz/
and http://github.com/ColdWind/pybugz/downloads/
Download
........
GitZilla is hosted at GitHub : http://github.com/gera/gitzilla
You can access the downloads at : http://github.com/gera/gitzilla/downloads
The download page contains a .deb which should work on Debian and Ubuntu
systems.
Mailing list
............
The official GitZilla mailing list: [email protected]