Mercurial_ The Definitive Guide - Bryan O'Sullivan [79]
Recall from Configuring the bugzilla hook that the user that runs the Mercurial process on the server is also the one that will run the processmail script. The processmail script sometimes causes Bugzilla to write to files in its configuration directory, and Bugzilla’s configuration files are usually owned by the user that your web server runs under.
You can cause processmail to be run with the suitable user’s identity using the sudo command. Here is an example entry for a sudoers file:
hg_user = (httpd_user)
NOPASSWD: /var/www/html/bugzilla/processmail-wrapper %s
This allows the hg_user to run a processmail-wrapper program under the identity of httpd_user.
This indirection through a wrapper script is necessary, because processmail expects to be run with its current directory set to wherever you installed Bugzilla; you can’t specify that kind of constraint in a sudoers file. The contents of the wrapper script are simple:
#!/bin/sh
cd `dirname $0` && ./processmail "$1" nobody@example.com
It doesn’t seem to matter what email address you pass to processmail.
If your usermap is not set up correctly, users will see an error message from the bugzilla hook when they push changes to the server. The error message will look like this:
cannot find bugzilla user id for john.q.public@example.com
What this means is that the committer’s address, john.q.public@example.com, is not a valid Bugzilla username, nor does it have an entry in your usermap that maps it to a valid Bugzilla username.
notify—Send Email Notifications
Although Mercurial’s built-in web server provides RSS feeds of changes in every repository, many people prefer to receive change notifications via email. The notify hook lets you send out notifications to a set of email addresses whenever changesets arrive that those subscribers are interested in.
As with the bugzilla hook, the notify hook is template driven, so you can customize the contents of the notification messages that it sends.
By default, the notify hook includes a diff of every changeset that it sends out; you can limit the size of the diff, or turn this feature off entirely. It is useful for letting subscribers review changes immediately, rather than clicking to follow a URL.
Configuring the notify hook
You can set up the notify hook to send one email message per incoming changeset, or one per incoming group of changesets (all those that arrived in a single pull or push).
[hooks]
# send one email per group of changes
changegroup.notify = python:hgext.notify.hook
# send one email per change
incoming.notify = python:hgext.notify.hook
Configuration information for this hook lives in the notify section of the ~/.hgrc file.
test: By default, this hook does not send out email at all; instead, it prints the message that it would send. Set this item to false to allow email to be sent. The reason that sending of email is turned off by default is that it takes several tries to configure this extension exactly as you would like, and it would be bad form to spam subscribers with a number of “broken” notifications while you debug your configuration.
config: The path to a configuration file that contains subscription information. This is kept separate from the main ~/.hgrc so that you can maintain it in a repository of its own. People can then clone that repository, update their subscriptions, and push the changes back to your server.
strip: The number of leading path separator characters to strip from a repository’s path, when deciding whether a repository has subscribers. For example, if the repositories on your server live in /home/hg/repos, and notify is considering a repository named /home/hg/repos/shared/test, setting strip to 4 will cause notify to trim the path it considers down to shared/test, and it will match subscribers against that.
template: The template text to use when sending messages. This specifies both the contents of the message header and its body.
maxdiff: The maximum number of lines of diff data to append to the end of