I have a server which hosts a mercurial repository with hgwebdir. Is it possible to make mercurial to run a script when someone pushes to this repository?
Currently I use a script that checks the repository state every few minutes, but this is obviously an ugly solution.
You have to add a hook to your Mercurial server:
Edit .hg/hgrc (or mercurial.ini on Windows)
Add or edit the [hooks] section
Associate a shell command to the hook you are interested in (in your case, the changegroup hook)
Look at Handling repository events with hooks in the Mercurial red-bean book for more details.
You might want to take a look at mercurial hooks,
http://hgbook.red-bean.com/read/handling-repository-events-with-hooks.html
Related
I have created a post-clone hook in .hg/hgrc. This hook sometimes executed, and sometimes not, depending on which directory hg is called from.
Let the repository be in /path/to/repos/. The post-clone hook is in /path/to/repos/.hg/hgrc.
Cloning from /path/to/repos/, the post-clone hook is executed:
$ pwd
/path/to/repos/
$ hg clone ./ /path/to/myclone/
Cloning from /path/to, the post-clone hook is not executed:
$ pwd
/path/to/
$ hg clone repos myclone
Why is the hgrc in my repository not read/post-clone hook not executed in the latter case?
Regards,
Freddy
I suspect you need to put the hook in your ~/hgrc file, rather than your repo's hgrc.
Hooks do not propagate
i.e.. if you add hook to a repo, then clone the repo, don't expect the hook to be in the new clone.
Here's the main text linked-to from Tom's answer, in case that page eventually changes or goes away:
Hooks do not propagate
In Mercurial, hooks are not revision controlled, and do not propagate
when you clone, or pull from, a repository. The reason for this is
simple: a hook is a completely arbitrary piece of executable code. It
runs under your user identity, with your privilege level, on your
machine.
It would be extremely reckless for any distributed revision control
system to implement revision-controlled hooks, as this would offer an
easily exploitable way to subvert the accounts of users of the
revision control system.
Since Mercurial does not propagate hooks, if you are collaborating
with other people on a common project, you should not assume that they
are using the same Mercurial hooks as you are, or that theirs are
correctly configured. You should document the hooks you expect people
to use.
In a corporate intranet, this is somewhat easier to control, as you
can for example provide a “standard” installation of Mercurial on an
NFS filesystem, and use a site-wide ~/.hgrc file to define hooks that
all users will see. However, this too has its limits...
That last warning may have been referring to the very next section which adds:
If you deploy a system- or site-wide ~/.hgrc file that defines some
hooks, you should thus understand that your users can disable or
override those hooks.
I have a mercurial server, running RhodeCode, that I commit my code to. My client has a Redmine installation and has requested that code I modify for them be stored on their server (understandable).
I would like to still commit to RhodeCode and after a successful commit, push these changes to their repository automatically. They have their code in both an SVN repository and a mercurial repository. I am allowed to commit to either - and they handle the synchronization between the two. My assumption is that it'd be easier to push to a mercurial repository.
I have a changegroup hook in mind, but I have a few technical questions on how this should work.
What is the best way to handle both receiving and pushing out to an external repository though?
User ----> RhodeCode ----> Redmine
At the RhodeCode step/changegroup hook, how do I forward on my changes? Can I do it directly from the main repository or am I forced to clone it into another directory and push that to the client?
Is there a better way to maintain my master repository and push my client's changes on?
I see no problem with this; the Mercurial hook in Buildbot works this way, doesn't it?
in order to bypass the JIRA-mercurial plugin, I need to replicate my (private) mercurial repository in a private mercurial repository in bitbucket. I and the other users will continue to "push" our commits to our own private repository, but I want pushed commits to be "forwarded" to a certain bitbucket repository. This way, I can use the JIRA's bitbucket plugin and see the changes related to my bugs.
In other words, I want that, after each push in my private mercurial repository, the commits are forwarded to my repository hosted by bitbucket. I think I should create a push hook, but I never used them before...
I think that the following hook (installed on my server) solves my problem...
[hooks]
changegroup = hg push ssh://hg#bitbucket.org/path/to/my/repository
(Pls, move it into comment of Matteo answer)
changegroup isn't correct type of hook for this task, because
The changegroup hook is activated once for each push/pull/unbundle,
unlike the commit hook, which is run once for each changeset
according to docs, and I suppose, more right way is
[hooks]
commit =
Depending on what mercurial client you are using, there are a number of different ways to have your local repository "push after commit".
The TortoiseHg windows client allows you to configure this per-repository for all commits (under the "settings->commit" dialog), as well as for individual commits under the "options" menu when committing.
There are also hook scripts that you can use. A quick google search finds many different options.
What are all steps required to validate commit message with set of regular expressions?
We want to work in semi-centralized set-up so I need a solution for the developer clone (local repository) and for our central clone (global repository). I read about Mercurial Hooks but I am a little bit lost how to put all things together.
For local repository I need a way to distribute validation script across my developers. I know that hooks do not propagate when cloning so I need to a way to "enable" them in each fresh clone. It would be done as a part of our PrepareEnvironement.bat script that we run anyway on each clean clone.
To be double safe I need similar validation on my global repository. It should not be possible to push into global repository commit that are not validating. I can configure it manually - it is one time job.
I am on Windows so installing anything except TortoiseHG should not be required. It was already a fight to get Mercurial deployed. Any other dependencies are not welcomed.
You can use the Spellcheck example as a starting point. In each developer's configuration, you need to use the following hooks:
pretxnchangegroup - Runs after a group of changesets has been brought into local from another repository, but before it becomes permanent.
pretxncommit - Runs after a new changeset has been created in local, but before it becomes permanent.
For the centralized repo, I think you only need the pretxnchangegroup hook unless commits can happen on the server, too. However, you will need the Histedit extension for each of the developers if the remote repo is the one rejecting one or more of the changesets being pushed. This extension allows them to "edit" already committed changesets. I would think in most cases, the local hooks will catch the issue, but like you said, "just in case."
More details about handling events with hooks can be found in the Hg Book.
I use the on-demand (hosted) version of FogBugz. I would like to start using Mercurial for source control. I would like to integrate FogBugz and a BitBucket repository.
I gave it a bit of a try but things weren't going very well.
FogBugz requires that you hook up your Mercurial client to a fogbugz.py python script. TortoiseHg doesn't seem to have the hgext directory that they refer to in instructions.
So has anyone successfully done something similar?
Post-mortem:
Bitbucket now has native fogbugz support, as well as other post-back services.
http://www.bitbucket.org/help/service-integration/
From the sounds of it you are wanting to run the hook on your local machine. The hook and directions are intended for use on the central server.
If you are the only one working in your repository or don't mind commit not showing up in FB until after you do a pull, then you can add the hook locally to your primary clone, If you are using your primary clone then you need to do something slightly different from what they say here:
http://bugs.movabletype.org/help/topics/sourcecontrol/setup/Mercurial.html
You can put your fogbugz.py anywhere you want, just add a path line to your [fogbugz] section of that repositories hgrc file:
[fogbugz]
path=C:\Program Files\TortoiseHg\scripts\fogbugz.py
Just make sure you have python installed. you may also wish to add a commit hook so that local commits to the repository also get into FB.
[hooks]
commit=python:hgext.fogbugz.hook
incoming=python:hgext.fogbugz.hook
On the Fogbugz install you will want change put the following in your for your logs url:
^REPO/log/^R2/^FILE
and the following for your diff url:
^REPO/diff/^R2/^FILE
When the hook script runs it connects to your FB install and sends it a few parameters. These parameters are stored in the DB and used to generate urls for diffs and log informaiton. The script sends the url of repo, this is in your baseurl setting in the [web] section. You want this url to be the url to your bitbucket repository. This will be used to replace ^REPO from the url templates above. The hook script also passes the revision id and the file name to FB. These will replace ^R2 and ^FILE. So in summary this is the stuff you want to add to the hgrc file in your .hg directory:
[extensions]
hgext.fogbugz=
[fogbugz]
path=C:\Program Files\TortoiseHg\scripts\fogbugz.py
host=https://<YOURACCOUNT>.fogbugz.com/
script=cvsSubmit.asp
[hooks]
commit=python:hgext.fogbugz.hook
incoming=python:hgext.fogbugz.hook
[web]
baseurl=http://www.bitbucket.org/<YOURBITBUCKETACCOUNT>/<YOURPROJECT>/
One thing to remember is that FB may get notified of a checkin before you actually push those changes to bitbucket. If this is the cause do a push and things will work.
EDIT: added section about the FB server and the summary.
Just a heads-up: Fog Creek has released Kiln which provides Mercurial hosting that's tightly integrated with FogBugz and doesn't require any configuration.
I normally wouldn't "advertise" on Stack Overflow (disclaimer: I'm one of the Kiln devs), but I feel that this directly answers the original question.
It is possible to integrate your GIT BitBucket repository with FogBugz issue tracker, but unfortunately it is not properly documented.
You have to follow steps described at https://confluence.atlassian.com/display/BITBUCKET/FogBugz+Service+Management, but beware that
In CVSSubmit URL you need to put url WITHOUT "?ixBug=bugID&sFile=file&sPrev=x&sNew=y&ixRepository=" parameters.
It should just be "https://your_repo.fogbugz.com/cvsSubmit.asp"
You will need to mention your FogBugz case ID in the git commit message
by putting "BugzID: ID" string in it (this is not documented
anywhere :-( ) similar to this:
git commit -m "This is a superb commit which solves case BugzID: 42"
Of course, commit info will be sent to FogBugz after you push your commit to BitBucket server, not after your do a local commit.