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.
