The first thing we need to do is installing TortoiseHg, a great freeware client to handle Mercurial repositories for all Windows platforms, including Windows Server 2012 and Windows 10. The installation packages, natively available for 32-bit and 64-bit Windows builds, are available free of charge from the project’s official website. This post shows setting up a Mercurial server on Windows/IIS using hgweb.cgi. Mercurial is a slippery slope. Sure, at first, you're just using it to keep a version history of files on your laptop, like a glorified version of CVS. Then you realize how easy it is to clone and sync your project, and pretty.

Browse to http://localhost/hg/test.cgi to see if it works

Mercurial is a DVCS that transfers code between your local system and Bitbucket Cloud. Follow the instructions on this page to install and set up Mercurial. If you write or deploy code to a remote machine, you may also need Mercurial on that machine as well.

The next thing to do is get a hold of hgweb.cgi, which isn't included in any of the Mercurial installations that were just performed as far as I can tell. One way to grab it is to browse the Mercurial source code here and download it, or you can cut and paste the following and save it to C:inetpubwwwroothghgweb.cgi.

This differs from Jeremy's guide because hgwebdir.cgi and hgweb.cgi were combined in Mercurial 1.6. The hgweb.cgi file now handles both single and multiple repositories.

If you've downloaded the file, open it up and change line 7 to match line 7 above. This is the location of the Mercurial configuration file.

Next, create an empty file and call it hgweb.config. More information will go into it later -- right now an empty file equates to default settings. At this point there should be four files in the C:inetpubwwwroothg directory.

• hgweb.cgi
• hgweb.config
• test.cgi
• web.config (created automatically to contain the CGI handler mapping)

That's enough to get Mercurial running. There's no need to copy the Mercurial library or template directory locally, that's what the Mercurial Python package was for. Browse to http://localhost/hg/hgweb.cgi and the following should be displayed.

Jeremy had a great suggestion at this point to create a rewrite rule to eliminate hgweb.cgi from the URL. To do this, URL Rewrite must be added to IIS 7.5 first. The easiest way to do that is to install Web Platform Installer and then install URL Rewrite 2.0 through that.

Now you can follow Jeremy's guide to create the rewrite rule via the interface, or you can cut and paste the <rewrite> section below into your web.config file, just after </handlers>.

Browse to http://localhost/hg to see the same screen as before.

Test Repo

Now to choose a location for the Mercurial repositories. I went with C:RepositoriesHg. To tell Mercurial about the location, open hgweb.config and modify it like so..

Create a new repo, Test, in the directory and refresh the browser.

This plugin integrates the Mercurial version control system with Jenkins.

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 are included for various hosted services. Avg pc tuneup 2013 serial key.

Push Notifications

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:

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 in Jenkins. This URL also doesn't require authentication even for secured Jenkins, 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 Jenkins 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.

As of version 1.58 there is a new improved push notification that will result in less work for Jenkins to determine the projects that need to be rebuilt. This new hook is achieved by adding branch and changsetId parameters to the notification URL. Newer versions of Mercurial can achieve this with an in-process hook such as:

or

Windows/TortoiseHG Integration

There are some caveats to running TortoiseHG on windows, particularly with ssh. Here are some notes to help.

Prerequisites:

• If you use 64bit TortoiseHG, you may need to run your Jenkins 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:Usersusernamemercurial.ini to use a specific key:

• 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 Jenkins 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 Jenkins service with the same account as TortoiseHG, which will allow it to complete.

Example, from a command prompt:

Click 'Yes' on the host key dialog. You can then cancel the next dialog prompting for password.

Main Configuration, Step by Step: Openfire android client example interview.

1. Install the Jenkins Mercurial Plugin.
2. Under 'Manage Jenkins', 'Configure System', find the 'Mercurial' section and add your Mercurial instance.

3. Save the configuration.

Job Configuration

Mercurial For Windows 10

1. Select Mercurial under Source Code Management
2. Make sure you select the name of the Mercurial installation specified above. In my case, 'TortoiseHG'
3. The url can either be ssh or https.

Example SSH URL:

Other Windows+TortoiseHG+ssh notes:

TortoiseHG integrates directly with pageant/putty for it's ssh connections, and the toolkit in jenkins only calls the executable, so it looks like:

Jenkins -> Mercurial Plugin -> TortoiseHG > plink/pageant

Therefore, Jenkins 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.

Environment Variables

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_SHORT: the short version of 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.

Auto Installation

Mercurial Server Windows Iso

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 agents 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 agents), Tool Home = usr, and configure a job with this installation tied to a Linux agent.

Version History

Versions 2.7 and later

See GitHub releases.

Earlier versions

Please refer to the changelog.