This plugin integrates the Mercurial version control system with Hudson.
With this plugin, you can designate a Mercurial repository as the "upstream" repository. Every build will then run something like hg pull -u to bring the tip of this upstream repository. In a similar manner, polling will check if the upstream repository contains any new changes, and use that as the triggering condition of the new build. This plugin is currently intended to support Mercurial 1.0 and later.
Viewers included are bitbucket, fisheye, google-code, hgweb, kiln, and rhodecode.
As of version 1.38 it's possible to trigger builds using push notifications instead of polling. In your repository's .hg/hgrc file add:[hooks]
commit.hudson = wget -q -O /dev/null <hudson root>/mercurial/notifyCommit?url=<repository remote url>
incoming.hudson = wget -q -O /dev/null <hudson root>/mercurial/notifyCommit?url=<repository remote url>
This will scan all the jobs that's configured to check out the specified URL, and if they are also configured with polling, it'll immediately trigger the polling (and if that finds a change worth a build, a build will be triggered in turn.)
This allows a script to remain the same when jobs come and go inHudson . This URL also doesn't require authentication even for securedHudson , because the server doesn't directly use anything that the client is sending. It runs polling to verify that there is a change, before it actually starts a build.
When successful, this will return the list of projects that it triggered polling as a response.
|| Jobs on Hudson need to be configured with the SCM polling option to benefit from this behavior. This is so that you can have some jobs that are never triggered by the post-commit hook, such as release related tasks, by omitting the SCM polling option.
There are some caveats to running TortoiseHG on windows, particularly with ssh. Here are some notes to help.
- If you use 64bit TortoiseHG, you may need to run your Hudson instance from a 64bit jvm to allow ssh support. If not, the initial clone will hang.
- For ssh support, you will either need putty/pageant installed to send the proper keys to the server if the keys are password protected, or you will need to specify the change in the ui section mercurial.ini found in C:\Users\username\mercurial.ini to use a specific key:[ui]
ssh="C:\program files\tortoisehg\TortoisePlink.exe" -i "C:\Users\username\key_nopass.ppk"
- To accept the host key, use plink or putty to connect to the server manually and accept the key prior to the initial clone. You can also use the tortoiseplink.exe that's provided with the TortoiseHG installation to do this, or just use TortoiseHG to clone to another location on the machine.
- If you are running Hudson as a Windows service, accessing pageant key will likely not work. In this case, use a key without passphrase configured in mercurial.ini
- The default installation runs windows service with "local system" account, which does not seem to have enough priveleges for hg to execute, so You could try running Hudson service with the same account as TortoiseHG, which will allow it to complete.
Example, from a command prompt: "C:\program files\tortoisehg\TortoisePlink.exe" firstname.lastname@example.org
Click 'Yes' on the host key dialog. You can then cancel the next dialog prompting for password.
Main Configuration, Step by Step:
- Install the Hudson Mercurial Plugin.
- Under "Manage Hudson", "Configure System", find the "Mercurial" section and add your Mercurial instance.
3. Save the configuration.
- Select Mercurial under Source Code Management
- Make sure you select the name of the Mercurial installation specified above. In my case, "TortoiseHG"
- The url can either be ssh or https.
Example SSH URL:ssh://email@example.com/myuser/projectname
Other Windows+TortoiseHG+ssh notes:
TortoiseHG integrates directly with pageant/putty for it's ssh connections, and the toolkit in Hudson only calls the executable, so it looks like:
Hudson -> Mercurial Plugin -> TortoiseHG > plink/pageant
Therefore, Hudson has no direct influence on the SSH key setup for the user. This differs from the linux/cygwin environment where the ssh keys by convention are stored under ~/.ssh.
The plugin exposes two new environment variables that can be used in build steps:
- MERCURIAL_REVISION: the changeset ID (SHA-1 hash) that uniquely identifies the changeset being built
- MERCURIAL_REVISION_NUMBER: the revision number for the changeset being built. since this number may be different in each clone of a repository, it is generally better to use MERCURIAL_REVISION.
The plugin supports generic tool auto-installation methods for your Mercurial installation, though it does not publish a catalog of Mercurial versions. For users of Linux machines (with Python preinstalled), you can use ArchLinux packages. For example, in /configure under Mercurial installations, add a Mercurial installation with whatever Name you like, Executable = INSTALLATION/bin/hg, Install automatically, Run Command, Label = linux (if desired to limit this to slaves configured with the same label), Command = [ -d usr ] || wget -q -O - http://www.archlinux.org/packages/extra/i686/mercurial/download/ | xzcat | tar xvf - (or …/x86_64/… for 64-bit slaves), Tool Home = usr, and configure a job with this installation tied to a Linux slave.
Version 1.35 (Jan 19 2011)
- issue #7723 Attempted fix for problem calculating changeset ID of workspace.
Version 1.34 (Nov 15 2010)
Version 1.33 (Aug 13 2010)
Version 1.32 (Aug 12 2010)
- issue #3602 Ability to specify a subdirectory of the workspace for the Mercurial repository.
- issue #6548 NPE when cache was out of commission.
Version 1.31 (Jun 10 2010)
Version 1.30 (May 17 2010)
- issue #6549 Mercurial caches for slaves was broken in 1.29.
Version 1.29 (May 12 2010)
- issue #6517 Reduce memory consumption representing merges in large repositories.
Version 1.28 (Mar 29 2010)
- issue #5835 Include repository browsing support for Kiln (patch by timmytonyboots).
Version 1.27 (Mar 19 2010)
- issue #4794 Option to maintain local caches of Mercurial repositories.
Version 1.26 (Mar 09 2010)
- issue #4271 Support parameter expansion for branch (or tag) field.
- issue #2180 Polling period can be set shorter than the quiet period now.
Version 1.25 (Nov 30 2009)
- issue #4672 Option to run Mercurial with --debug.
- Dropping support for Mercurial 0.9.x. Use 1.0 at least.
- issue #4972 Do not consider merge changesets for purposes of polling.
- issue #4846 Option to download Forest extension on demand. Useful for hard-to-administer slaves.
- Restoring ability to specify Mercurial executable name other than INSTALLATION/bin/hg (lost in 1.17 with move to tool installation system).
- issue #1099 Make "modules" list work even after restart.
Version 1.24 (Nov 13 2009)
Version 1.23 (Oct 23 2009)
- Module list should filter the changelog as well as polling. (issue #4702)
- Implement getAffectedFiles in MercurialChangeSet r22903.
Version 1.22 (Sep 23 2009)
Version 1.21 (Sep 22 2009)
Version 1.20 (Sep 21 2009)
- issue #4514 alternate browsers do not show up in dropdown after updating the plugin. This is an intermediate
quick fix until version 1.325 of the core is released.
Version 1.19 (Sep 20 2009)
- issue #4461 fix was leaking threads.
- Mercurial changelog now links to diffs and specific revisions of files (issue #4493)
Version 1.18 (Sep 18 2009)
- 1.17 release was botched (Maven issue), rereleasing as 1.18.
Version 1.17 (Sep 18 2009)
- Fixed various issues with named branches. (issue #4281)
- If switching to clone due to path mismatch, at least explain what is happening in the build log. (issue #1420)
- Kill Hg polling process after one hour, assuming it is stuck on a bad network connection. (issue #4461)
- Multiple Mercurial installations may now be configured as tools. See Tool Auto-Installation for background.
- Environment variable "MERCURIAL_REVISION" that contains the node ID like "272a7f93d92d..." is now exposed to builds. (Also retain ID of tip revision for each build; not yet exposed via XML API or GUI but could be useful later.)
- Google Code and BitKeeper can be now specified (in addition to hgweb) as a repository browser (issue #4426)
Version 1.16 (May 27 2009)
- The plugin was failing to clean up tmp*style file if the check out failed. (issue #3266)
- Fixed a file descriptor leak (issue #2420)
- Fixed implementation of clean update. (issue #2666)
- Choose the hgweb source browser automatically. (issue #2406)
- Hudson clones (never updates) when repo path ends with (issue #2718)
- Fixed a bug in the polling and branch handling (report)
- Exposed the details of the changelog to the remote API.
- Fixed a polling bug in the distributed Hudson (report)
- Added an option to perform clean update.
- Supported "modules" so that Hudson won't start builds for changes outside your module in hg (discussion)
- The plugin now correctly handles special XML meta-characters (such as ampersands) in filenames.
- Correcting hgrc parser to not print warnings about valid config files.
- Missing help file added.
- Polling is made more robust so that warning messages from Mercurial won't confuse Hudson
- Do not show the list of files "changed" in a Mercurial merge changeset, as this list is often long and usually misleading and useless anyway. In the unusual case that you really wanted to see the details, you can always refer to hgwebdir or the command-line client.
- Fixed a bug in hgweb support URL computation (issue #1038)
- Fixed a MalformedByteSequenceException (report)
- Perform URL normalization on hgweb browser URL (issue #1038)
- Fixed a bug in escaping e-mail address (report)
- Improved error diagnostics when 'hg id' command fails.
- Added branch support (issue #815)
- Help text was missing
- Added version check to the form validation.
- Updated to work with behavior changes in hg 0.9.4 (this plugin can still work with 0.9.3, too)
- Plugin now works with slaves.
- "hg incoming" now runs with the --quiet option to avoid status messages from going into changelog.xml
- fixed crucial bug where "hg pull" was run even if "hg incoming" didn't find any changes.