- Simon Waight
As part of the journey our team is going on in 2012 I am looking to migrate our processes and tools to a more scalable and maintainable state. One of the first items to look at was the replacement of that early cornerstone of CI – CruiseControl. Our existing server was aging and was running on a platform that meant Azure SDK support was unavailable. To resolve this I moved to a new machine and new CruiseControl build only to discover that the Mercurial features don't work.
After an initial clone the CC builds failed – having spent time investigating I decided to see what else was about that allowed us to do centralised builds. Bearing in mind this is a transition state I didn't want invest a huge amount of time and money in a solution and found the Jenkins CI offering online. As a bonus it has support (via plugins) for Mercurial and MSBuild so it seemed to fit the bill.
As is always the way things didn't quite work as I wanted. Our existing build setup utilises HTTP authentication and not SSH to connect to our hosted Mercurial repositories and when I setup new Jenkins builds I was seeing that each build would clone the entire remote repository again which in some instances is not desirable given their size. This is what I saw at the top of my build console log:
Started by user anonymous Building in workspace E:\Program Files (x86)\Jenkins\jobs\XXXXXXXXX\workspace [workspace] $ hg.exe showconfig paths.default ERROR: Workspace reports paths.default as https://AAAAAAAA@bitbucket.org/BBBBB/XXXXXXXXX which looks different than https://AAAAAAAA:PPPPPPPP@bitbucket.org/BBBBB/XXXXXXXXX so falling back to fresh clone rather than incremental update
So I was scratching my head about this - we've always used the inline auth approach but it looked like in this instance the Jenkins Mercurial plugin / Mercurial client was deciding that the inline authentication made the source different enough that it wouldn't even attempt to do a pull.
Digging around I discovered that the hg command line supports use of "ini" files to set global parameters. I could theoretically have just set this in the baseline ini file that comes with the Mercurial client but as that file says "any updates to your client software will remove these settings."
So, how to resolve?
Here are the steps I followed to resolve:
Create a new non-admin windows login with a valid password.
Grant this login control of the Jenkins folder (and any others that Jenkins may read / write / update).
Open up Windows Services and change the Jenkins service logon to be the new logon from (1).
Create a .hgrc file in the new windows login's "C:\Users<username>" folder with these contents:
[auth] bitbucket.prefix = bitbucket.org/BBBBB bitbucket.username = AAAAAAAA bitbucket.password = PPPPPPPP
Restart the Jenkins Windows Service.
Now when you run your build you will see a much more expected site:
Started by user anonymous Building in workspace E:\Program Files (x86)\Jenkins\jobs\XXXXXXXX\workspace [workspace] $ hg.exe showconfig paths.default [workspace] $ hg.exe pull --rev default [workspace] $ hg.exe update --clean --rev default 0 files updated, 0 files merged, 0 files removed, 0 files unresolved
Hopefully this post will save you some time if you're trying to achieve the same sort of thing for your team.