Add support for the bugzilla rest api documented at
https://wiki.mozilla.org/Bugzilla:REST_API
and at
https://bugzilla.readthedocs.io/en/latest/
This backend has the following benefits:
* It supports the bugzilla api keys so hgrc does not need to contain
a user's bugzilla password
* Works with Mercurial's "hostfingerprints" support making handling
bugzilla instances with self-signed certs easier
* Does not use xmlrpc ;-)
Adds configuration item 'apikey' in [bugzilla] section.
My major concern with these patches is if the approach to HTTP access
is the right way for an extension and if hooking into request object
and the overriding the get_method to perform PUT requests was a
sensible approach.
# no-check-commit
I've caught multiple extensions in the wild lying about being
'internal', so it's time to move the goalposts on people. Goalpost
moving will continue until third party extensions stop trying to
defeat the system.
This prepares for the API change to support template aliases. I'm going to
extract a factory function of templater that reads a map file:
# original
templater(mapfile, ..., cache, ...)
# new
templater.frommapfile(mapfile, ...) # read mapfile to build cache/map
templater(..., cache, ...) # use specified cache (= map elements)
This will make it clear to isolate stock styles (i.e. map files) from user
aliases. Template aliases should be applied to command arguments and templates
in hgrc, but not to map files. Otherwise, our stock styles and web templates
could be modified unintentionally.
This patch makes sure that either "tmpl" or "mapfile" is exclusively set. It's
theoretically a behavior change, since you could put new keywords in template
by defining them in a map file before:
# mapfile
foo = "{rev}"
# hgrc
[bugzilla]
style = mapfile
template = {foo}
But the old behavior would be a bug because bugzilla.template is documented
as "overrides style if specified". Also, common log-like templates and
formatter doesn't allow using mapfile-keywords in a separate template. So
I decided to make a BC.
Since there was no test for the bugzilla extension, this adds new test that
covers style/template output.
The home of 'Abort' is 'error' not 'util' however, a lot of code seems to be
confused about that and gives all the credit to 'util' instead of the
hardworking 'error'. In a spirit of equity, we break the cycle of injustice and
give back to 'error' the respect it deserves. And screw that 'util' poser.
For great justice.
Python 2.6 introduced the "except type as instance" syntax, replacing
the "except type, instance" syntax that came before. Python 3 dropped
support for the latter syntax. Since we no longer support Python 2.4 or
2.5, we have no need to continue supporting the "except type, instance".
This patch mass rewrites the exception syntax to be Python 2.6+ and
Python 3 compatible.
This patch was produced by running `2to3 -f except -w -n .`.
Extension authors (notably at companies using hg) have been
cargo-culting the `testedwith = 'internal'` bit from hg's own
extensions, which then defeats our "file bugs over here" logic in
dispatch. Let's be more aggressive about trying to give extension
authors a hint about what testedwith should say.
In the context of standalone Hg receiving a set of incoming changes, it makes
sense for the Bugzilla module to cache basic setup to avoid reconnecting
to Bugzilla for each change. After processing the changes, Hg will exit
and so the connection is short-lived.
But this doesn't work too well when used from a long-lived environment
such as hgweb or Kallithea where, for example, the connection can time out.
So take the simple approach, abandon the cache and do the basic setup on
each call. This fixes current problems with Kallithea.
Bugzilla 4.4.3 and later remove the old cookie based session authentication
from the Web Services API and replace it with a login token. The session
can now also be restricted to the originating IP.
Add the necessary to the extension so it works with 4.4.3 and later.
Some of the formatting details required for bug submission via email
changed between Bugzilla 3.4 and 3.6. Bugzilla 3.4 requires lines of
the form '@fieldname = value', while 3.6 wants '@fieldname value'.
Also the field @bug_id in 3.4 becomes @id in 3.6.
Bugzilla up to and including 4.0 also recognises the 3.4 format. To save
surprises in the future, check the Bugzilla version and use the 3.6
format from all major versions >= 4. At some point we will
drop support for Bugzilla prior to 3.6 and support the new format only.
Add a second regular expression used when scanning change comments.
Bugs matched by this new regular expression have the bug comments and
optionally hours updated as with the first regular expression, but they
are also marked as fixed.
The bug status and resolution to set to mark a bug as fixed can be
configured. By default status is set to RESOLVED and resolution to
FIXED, the default Bugzilla settings.
For example, a change comment containing 'Fixes 1234 h1.5' will be
added to bug 1234, the bug will have its working time increased by
1.65 hours, and the bug will be marked RESOLVED/FIXED.
Change comments may contain both bug update and fix instructions. If
the same bug ID occurs in both, the last instruction found takes
precedence.
The patch adds new bug states 'bug_status' and 'resolution' and actions
to update them to the XMLRPC and XMLRPC/email access methods. XMLRPC does
not support marking bugs as fixed when used with Bugzilla versions prior
to 4.0. When used with an earlier Bugzilla version, a warning is issued
and only comment and hours updated.
If an 'hours' group is present in the bug matching regular expression,
and that group contains a float value, update the bug working time in
Bugzilla with those hours.
The patch adds a key 'hours' to the bug state dictionary, and adds
support for the key to the XMLRPC and XMLRPC/email access methods.
The MySQL access method is not supported; a warning is given.
As a first step to allowing comment text to update bug state, rework the
Bugzilla access interface to use a dictionary keyed on bug ID. Dictionary
entries will contain new state info in future changes.
Python 2.7 introduced support for gzip encoding in xmlrpclib.Transport.
We do our own handling of responses, and don't currently support gzip encoding.
So to run successfully under Python 2.7 with a web server configured
to gzip encode, stop XMLRPC requests from announcing gzip encoding support.
Inadvertently support is currently only for https. For some reason I
thought xmlrpclib.SafeTransport did http and https, but it is https only.
So create http and https XMLRPC transports that retain cookies. Decide which
to use by inspecting the Bugzilla URL.
Correct typo in numbering list of access methods.
Convert a section reference and a template parameter reference into
literal text, for consistency with other use.
Use consistent sample domains and wording in all configuration examples.
Add missing template and strip parameters to XMLRPC examples and correct
Bugzilla URL key in XMLRPC+email.
