• Choose a category
• All
• Classic-Fiction

db: The name of the Bugzilla database on the MySQL server. The default value of this item is bugs, which is the standard name of the MySQL database where Bugzilla stores its data.

notify: If you want Bugzilla to send out a notification email to subscribers after this hook has added a comment to a bug, you will need this hook to run a command whenever it updates the database. The command to run depends on where you have installed Bugzilla, but it will typically look something like this, if you have Bugzilla installed in /var/www/html/bugzilla:cd /var/www/html/bugzilla &&

./processmail %s nobody@nowhere.com

The Bugzilla processmail program expects to be given a bug ID (the hook replaces %s with the bug ID) and an email address. It also expects to be able to write to some files in the directory that it runs in. If Bugzilla and this hook are not installed on the same machine, you will need to find a way to run processmail on the server where Bugzilla is installed.

Mapping committer names to Bugzilla usernames

By default, the bugzilla hook tries to use the email address of a changeset’s committer as the Bugzilla username with which to update a bug. If this does not suit your needs, you can map committer email addresses to Bugzilla usernames using a usermap section.

Each item in the usermap section contains an email address on the left, and a Bugzilla username on the right:

[usermap]

jane.user@example.com = jane

You can either keep the usermap data in a normal ~/.hgrc, or tell the bugzilla hook to read the information from an external usermap file. In the latter case, you can store usermap data by itself in (for example) a user-modifiable repository. This makes it possible to let your users maintain their own usermap entries. The main ~/.hgrc file might look like this:

# regular hgrc file refers to external usermap file

[bugzilla]

usermap = /home/hg/repos/userdata/bugzilla-usermap.conf

while the usermap file that it refers to might look like this:

# bugzilla-usermap.conf - inside a hg repository

[usermap] stephanie@example.com = steph

Configuring the text that gets added to a bug

You can configure the text that this hook adds as a comment; you specify it in the form of a Mercurial template. Several ~/.hgrc entries (still in the bugzilla section) control this behavior.

strip: The number of leading path elements to strip from a repository’s pathname to construct a partial path for a URL. For example, if the repositories on your server live under /home/hg/repos, and you have a repository whose path is /home/hg/repos/app/tests, then setting strip to 4 will give a partial path of app/tests. The hook will make this partial path available when expanding a template, as webroot.

template: The text of the template to use. In addition to the usual changeset-related variables, this template can use hgweb (the value of the hgweb configuration item above) and webroot (the path constructed using strip above).

In addition, you can add a baseurl item to the web section of your ~/.hgrc. The bugzilla hook will make this available when expanding a template, as the base string to use when constructing a URL that will let users browse from a Bugzilla comment to view a changeset. For example:

[web]

baseurl = http://hg.domain.com/

Here is an example set of bugzilla hook config information:

[bugzilla]

host = bugzilla.example.com

password = mypassword version = 2.16

# server-side repos live in /home/hg/repos, so strip 4 leading

# separators

strip = 4

hgweb = http://hg.example.com/

usermap = /home/hg/repos/notify/bugzilla.conf

template = Changeset {node|short}, made by {author} in the {webroot}

repo, refers to this bug.\n

For complete details, see

{hgweb}{webroot}?cmd=changeset;node={node|short}\n

Changeset description:\n

\t{desc|tabindent}

Testing and troubleshooting

The most common problems with configuring the bugzilla hook relate to running Bugzilla’s processmail script and mapping