Labels and automated builds.... How?

Guest · Post by **Guest** » Mon May 23, 2005 11:59 am

Ok, here we go. I ahve the requirement that we use vcontinuous integration and fully automated build scripts, while still labelling every build.

The main issue hereby is that our automated builds wil check out one or more of the files - these files contain version information and need to be updated to the last build number. In addition, a file containing, in xml form, the last build number, also needs to be checked out.

And - the label should, by any means, include the changes on this file. While, at the same time, people are working on the source archive. So I can not just go out (imho) and issue a "label" operation.

What happens is (or what should happen is):

* System labels the current version in the tree with a temporary label.
* System performs a get operation on this temporary label.
* System checks out and upgrades information in some files. Check-Out is exclusive.
* System performs full build, and deployment and all other stuff.
* System needs to:
* * Check in the changed files AND
* * change the temporary label to the final label AND
* * change the content of this label to include the latest versions of said files.

It would be easier if I could run a label operation on the currently stored version I have (i.e. as part of a transaction, in the command line). Issue at hand is that the operation MUST be atomic from the source control poitn of view - if, between our checkin and our finalizing, a file is changes, it is not acceptable that the label gets attached to the wrong version. This would kill the reliability of being able to reproduce the build, which is a critical issue here. Mostly because occasionally we will get a specific label version (as a release) and run more extensive tests, get documentation and setup files generated and will "re-publish" this build to customers.

Anyone an idea how to handle this? The environment is Nant, which means the sourcegear command line. My main issue is that I do not know how to guarantee that the changed check-in files get assigned to the new label. Easiest way would be to assign the label after the checkin, but then - this would really blow the integrity guarantee, especially as builds can take a couple of minutes.

Post by **jeremy_sg** » Mon May 23, 2005 7:59 pm

There's a lot that you want to be able to do, and Vault can do it all, but parts of it are not exposed through the command line client or the nant tasks.

* System labels the current version in the tree with a temporary label.
* System performs a get operation on this temporary label.
* System checks out and upgrades information in some files. Check-Out is exclusive.
* System performs full build, and deployment and all other stuff.
* System needs to:
* * Check in the changed files AND

All of these things can be done now, either with the CLC or the nant tasks.

* * change the temporary label to the final label AND
* * change the content of this label to include the latest versions of said files.

These things are not currently exposed through the CLC or nant tasks. If you're brave, I'm willing to walk you through the CLC code which is available, and provide you sample code to promote and rename a label.

GregM · Post by **GregM** » Mon May 23, 2005 8:00 pm

This is what we do for our automated builds:

Check out the version number file.
Bump the version number.
Check in the version number file.
Label the current tree.
Get the label that was just added.

GregM · Post by **GregM** » Mon May 23, 2005 8:32 pm

The main problem with using label promotion for this is that Vault can not currently branch a label once it has been promoted.

Guest · Post by **Guest** » Tue May 24, 2005 12:47 am

GregM wrote:This is what we do for our automated builds:

Check out the version number file.
Bump the version number.
Check in the version number file.
Label the current tree.
Get the label that was just added.

My problem with this approach is that - this ups the version number EVEN if the build then fails.

It is a nice approach, though. I could split the operation - we use cc.net - and use multiple cc.net nant tasks to perform this:

* get version number file, check out, increase build number, check in.
* Label source tree.
* Get label.
* Build and deploy.

You are right, this would handle the issue at hand. Not necessarily perfect, but well enough. I will ahve to ask around on the ccnet users list about passing the string with the version number (not the cc.net build number) to the tasks, though.

Still, I would be counting upward in the build numbers EVEN if a build fails. Not sure I like it. But I could propably live with it.