We are using cruise control .net with mercurial version control for continuous integration.
I want to get the latest build number in the ccnet dashboard.
While using toroise svn as version control we added <labeller type="lastChangeLabeller"/> to get the latest build number. So while using mercurial hg, what tag should be added in order to get the latest build number? Can anyone help me on this.
I don't know what it looks like in cruise control (people still use cruise control?!), but from mercurial you can use: hg log -r . --template '{node}-{latesttag}-{latesttagdistance}' to get the string you want. You can exec that and get the value either in CC or in your build scripts.
Related
How do I configure Hudson/Jenkins (we're still using Hudson) to build all branches with the mercurial plugin? I have seen that we can create separate jobs/etc for specific branches, but we branch often enough that it would be good to just build all branches.
The only way I can think of (and I haven't tried it) is to have our build script [executed by Hudson on the slave] somehow figure out which branch is the latest commit and then hg update -r itself, rather than the mercurial plugin doing it.
I would love to find out a more elegant/correct way to do this!
I've also been looking for this support in the Jenkins Mercurial plugin (partly because it's supported by its Git plugin) but the following Jenkins tickets seem to indicate that this is yet not implemented:
https://issues.jenkins-ci.org/browse/JENKINS-11102
https://issues.jenkins-ci.org/browse/JENKINS-10558
One option if you have branches that are used regularly (ie, named branches for milestones or developers) is to create copies of your master build and simply point it to that branch.
For example on my team's build server we have production ('default' branch) and development ('dev' branch). Our builds are run by feeding the branch name as a parameter to the build script (so it's a simple, one-field change from a copy of the main job).
Obviously this won't scale beyond a handful of branches, but it might be enough for your needs.
I would like to be able to present a view of Jenkins builds similar to the buildbot console view. With Jenkins out of the box, there appears to be really no good way to associate a commit with a build. You have to access the specific built to determine what commit it was building.
I would like to be able to show status on what commits have been tested in a particular branch, so we know if a commit was skipped or if the latest commit has not yet been tested.
I tried using the Jenkins API for this, but I found that I could only see the SHA1 hash for a git commit via the build itself, i.e. via http://server/job/job-name/388/api/json. So, the only way I can see to take a commit and find builds for it is to iterate through every build in a job and retrieve its associated build info. This is certainly not going to be efficient and fast. Is there another way to do it?
Imperfect Answer: put the "revision number" you care about in the package name of all related artifacts, and use the "fingerprint" feature.
For example: my "product package" artifacts have a revision number, and if I carried that through to the "test package" artifact (which includes the unpacked product artifact) you would be able to track that revision number via the "artifact/fingerprint" feature, and show which test jobs used it. Below, you can't tell with a single click which test used which "commit."
I've got a Mercurial database that I want to migrate to Perforce and preserve all the changes. Tell me a way I can do this.
Update Mar/2013:
Just to make the informations up to date:
svn -> p4
There is a new tool called p4convert-svn:
p4convert-svn doc
Beware of filesystem case in/sensitivity.
hg -> p4
Following tool is not mentioned a lot, but it's recommended by perforce support:
hg convert p4 sink depot
It adds p4 sink into hg convert extension. Disadvantage is that it fits in mercurial 1.7.3 which is a bit outdated as of today (current is 2.2.5). It can be merged by hand easily into 2.0.2 version which may be sufficient even for largefile extension users.
For more information read file Readme-P4.txt in the depot.
One way that I thought of doing this is to clone the repository into my workspace and execute a python script to do the migration. The script would loop through each revision starting with 0 and ending with the tip, checking in files to p4 along the way.
I figure that I can get all the changeset comments via the log command, then I can use hg log -r i --template {rev}: {file_adds}|{file_dels}|{file_mods}\n, where i is the current revision, to get the files that were added, removed, renamed, etc. When I notice that I'm on a new branch, I can check for the branch in P4 and create it if necessary.
At the end of the day, all that stuff should be checked in accordingly to P4.
Take a look at the Perforce section of the Mercurial wiki page on Converting Repositories. There seems to be support for pushing changes from Mercurial to Perforce.
I have recently started researching how to migrate an Alienbrain repository to Perforce. As there are no tools publicity available to do this, my research had lead to several resources on how to write your migration program.
Read the "Migration Planning Guide" on the Perforce website (pdf link). The document is written for ClearCase to Perforce, however the three approaches are still relevant. In particular, have a look at the "Baseline Branch Import" technique to see if that would make sense for you.
Download a copy of svn2p4sync from Tigris (link) as it is one of the most tested migration scripts available. Whilst on the Tigris site, read the svn2p4sync release notes/issues page for a good history of how the script was developed (link).
I've also just found the Generic Conversion page (link) on the Mercurial wiki (thanks to the link in Wim Coenen answer).
Edit: for your specific case where there is a script, I would recommend you use the linked in Wim Coenen answer (link).
HTH,
If I set up a central Mercurial Repository where certain people are allowed to push to it, what convenient way can I monitor the changes going into that repository?
I'm used to using SVN-Monitor for Subversion. It runs in the task-bar and lets me know whenever something new has been checked in to the repository.
Is there a similar solution for Mercurial ?
This tool looks like it might be what you're after.
Use a RSS feed monitor and point it to the repo's atom/RSS feed (found in the web interface).
Something like this should do nicely: https://superuser.com/questions/9929/rss-notification-in-system-tray
Alternately you could set up a changegroup hook on the repo to be watched and have it trigger something on your system, but polling is probably okay for this.
If you are currently using TeamCity or looking for a Continuous Integration solution:
TeamCity has various apps/plugins like a VisualStudio plugin and Windows TrayIcon for build notifications. You set up a project in TeamCity to build when someone commits to the repository. When someone commits it triggers a build, which will send a notification to you. A bonus is that it tells you if the build succeeded or failed ==> {good code or bad code}
Been giving HgAssist a try it works pretty well.
I'm working on setting up a Hudson/Mercurial stack for development. One of the use cases I have is "As a developer, I want to update my local sandbox to a particular build number from Hudson, so I can [fix a bug, debug issues, create a branched version of code, etc.]."
So, if I see build #49 on Hudson, how do I update my local Mercurial repo to the same source code that was used to build #49?
Note: I have looked at Mercurial tags, however they don't seem quite appropriate. They require a commit, so it seems the commits will dirty up the history (each commit by a developer will show a subsequent commit from the tag operation). If this is the best there is, I guess I will have to live with it, but hoping for something better. Would probably still use tags for releases.
Ok, here's the solution I ended up with:
Using the Description Setter Plugin, I set both the success and failing build description to "Mercurial ${MERCURIAL_REVISION}". Turns out the current Mercurial SCM plugin sets this environment variable to the parent changeset id.
I can then look at a build on Hudson, and if so desired, grab the changeset id and do a "hg update " on my local repo to get that revision of code.
Note that in the Mercurial plugin issue tracker there is some talk of changing this to HG_REVISION instead and adding other environment variables, so this may break at some point in the future, but works for me for now.
You can use the keywords extension on the hudson system to update the nodeid into some aspect of the build, possibly including the artifact names. If the Hudson job output artifacts are like: myproject-2010-02-17-2dbf7575fa46.tar.gz you certainly know how to 'hg update' to that point in time.
The keywords extension and maybe a little ant-fu make that easy to do.