In order to integrate our Mercurial repository and our bug tracker (Bugzilla 4.0.1), I have set up the server-side hgrc file like this:
[extensions]
hgext.bugzilla=
[hooks]
incoming.bugzilla=python:hgext.bugzilla.hook
[bugzilla]
bzurl=http://localhost/bugzilla
[email protected]
password=password
version=xmlrpc
hgweb=http://this-server:65432/
template=Changeset {node|short} in {root|basename}.\nDetails siehe {hgweb}{webroot}?cmd=changeset;node={node|short}\nBeschreibung:\n\t{desc|tabindent}
[usermap]
committer_email=bugzilla_user_name
[web]
push_ssl=False
allow_push=*
baseurl=http://this-server:65432
Mercurial is set to serve on this-server, port 65432.
Now, after starting hg serve
, the very first push will be handled just fine. All bug references found in the commit messages will generate Bugzilla comments. But on every subsequent push with at least one bug reference present, the following error message is presented to the user:
pushing to http://this-server:65432/
searching for changes
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files
remote: error: incoming.bugzilla hook failed: Bugzilla error:
On several occasions, this message has been observed:
remote: error: incoming.bugzilla hook failed: Bugzilla error: [Errno 54] Connection reset by peer
No comments are created in bugzilla. Restarting hg will make it work exactly once again.
I have also tried starting the Mercurial server with arguments -A ... -E ...
to have it create access and error logs. The access log shows the same kind of interaction for every request, regardless if successful or not:
192.168.117.78 - - [20/Feb/2013 10:19:03] "GET /?cmd=capabilities HTTP/1.1" 200 -
192.168.117.78 - - [20/Feb/2013 10:19:03] "GET /?cmd=batch HTTP/1.1" 200 - x-hgarg-1:cmds=heads+%3Bknown+nodes%3Dc3ee38280c255a62c2742304622d8fcf29959863+b8cbc9948834a83b9a8f6dd9f1b96d5f39224324+54f5e40379910d6026b8656fe0982bb5b7e9e22b
192.168.117.78 - - [20/Feb/2013 10:19:03] "GET /?cmd=branchmap HTTP/1.1" 200 -
192.168.117.78 - - [20/Feb/2013 10:19:03] "GET /?cmd=branchmap HTTP/1.1" 200 -
192.168.117.78 - - [20/Feb/2013 10:19:04] "GET /?cmd=listkeys HTTP/1.1" 200 - x-hgarg-1:namespace=bookmarks
192.168.117.78 - - [20/Feb/2013 10:19:09] "POST /?cmd=unbundle HTTP/1.1" 200 - x-hgarg-1:heads=686173686564+be8d19f7ab04e73ad36715ec876b4dd74384a920
192.168.117.78 - - [20/Feb/2013 10:19:09] "GET /?cmd=listkeys HTTP/1.1" 200 - x-hgarg-1:namespace=phases
192.168.117.78 - - [20/Feb/2013 10:19:09] "POST /?cmd=pushkey HTTP/1.1" 200 - x-hgarg-1:key=54f5e40379910d6026b8656fe0982bb5b7e9e22b&namespace=phases&new=0&old=1
192.168.117.78 - - [20/Feb/2013 10:19:10] "GET /?cmd=listkeys HTTP/1.1" 200 - x-hgarg-1:namespace=bookmarks
192.168.117.78 - - [20/Feb/2013 10:20:04] "GET /?cmd=capabilities HTTP/1.1" 200 -
192.168.117.78 - - [20/Feb/2013 10:20:05] "GET /?cmd=batch HTTP/1.1" 200 - x-hgarg-1:cmds=heads+%3Bknown+nodes%3Dc3ee38280c255a62c2742304622d8fcf29959863+b8cbc9948834a83b9a8f6dd9f1b96d5f39224324+7fbb4c09e39db549ed01532785e80eda480e8862
192.168.117.78 - - [20/Feb/2013 10:20:05] "GET /?cmd=branchmap HTTP/1.1" 200 -
192.168.117.78 - - [20/Feb/2013 10:20:05] "GET /?cmd=branchmap HTTP/1.1" 200 -
192.168.117.78 - - [20/Feb/2013 10:20:05] "GET /?cmd=listkeys HTTP/1.1" 200 - x-hgarg-1:namespace=bookmarks
192.168.117.78 - - [20/Feb/2013 10:20:05] "POST /?cmd=unbundle HTTP/1.1" 200 - x-hgarg-1:heads=686173686564+f71bb72e20c8f91b9d0ca3b5fbdef2aac667c265
192.168.117.78 - - [20/Feb/2013 10:20:05] "GET /?cmd=listkeys HTTP/1.1" 200 - x-hgarg-1:namespace=phases
192.168.117.78 - - [20/Feb/2013 10:20:06] "POST /?cmd=pushkey HTTP/1.1" 200 - x-hgarg-1:key=7fbb4c09e39db549ed01532785e80eda480e8862&namespace=phases&new=0&old=1
192.168.117.78 - - [20/Feb/2013 10:20:06] "GET /?cmd=listkeys HTTP/1.1" 200 - x-hgarg-1:namespace=bookmarks
The error log is empty.
How can I further diagnose this issue?
The hg serve
invocation is not for long term use. It's for "hey, clone this thing I started on" between buddies on a LAN. From the Mercurial wiki
It is not really recommended except for temporary situations where you need to publish a repository for a few minutes, for example to pull changes from a laptop.
I suspect if you spin up a real wsgi container things will work. I've not used the bugzilla hook, but I'm guessing it's not cleaning up after itself since it's expects to be in a wsgi container or command line invocation that gets cleared away.