Labelling dilemna

[bnott]

I am using CC.NET for automated builds.

As a part of the build, AssemblyInfo.cs files are updated with the new build label for their version. At the end of the build, the log files and redistributables are checked in to vault.

Then the vault source control block applies the label. The label gets applied to folder version of when the source was gotten. However, this does not include the updated AssemblyInfo.cs files, log files, and redistributables.

So I need a way to apply the label to the gotten folder version, plus those files I checked in as apart of the build. I'm guessing this is what label promotion is for.

But,
1) It looks like label promotion isn't supported on the command line. Will it ever be?
2) The docs for label promotion says you then can't branch on the label. This will be a problem.
3) There is not support in the vault source control block for CC.NET to give me the folder version, so I wouldn't be able to apply the label myself.


Does anyone have any suggestions for dealing with this scenario? Is there a better approach that would eliminate the label promotion girations?

Thanks,
Brian

[jclausius]

Brian:

I'm not sure I have an answer for your questions.

You could place your binaries/outputs from builds back into the repository, but since it isn't really necessary to track changes on these files, it is usually recommended to use normal archival methods when backing up these kinds of files.

In regards to the AssemblyInfo.cs file, I don't have an answer except label promotion. We do plan to add branch support for promoted labels, but that feature is still down the road. As a work around for branching, if it is just the one file that is being promoted, you could look at the version the label is created, and then branch the historical folder version.

For what its worth, I can say in our build process here we only commit changes for major, minor, and revision versions. Build numbers themselves are not checked into the tree. The reasoning is the build number is exactly that a build number. Each and every build should have its own unique number, even if it is built from the exact same source pulled from a label.


We have a feature request for a way to get the version number of a folder. I'll add your post to that request.

[bnott]

OK, so branching on promotions might be coming. In the mean time, how do I promote using the command line client?

I don't need to be able to get a version number of a folder. The version number of the folder the CC.NET Vault Source Block gets just needs to be set as the ChangeNumber for the Modification entry it creates for the IntegrationResult of CC.NET. Right now its using the txid instead.

Thanks,
Brian

[jclausius]

OK, so branching on promotions might be coming. In the mean time, how do I promote using the command line client?

That functionality is not in the CLC.

I've added a feature request for that as well.

[dschreiber]

We're having the same problem with CC.NET generating some database scripts during our nightly build process that we check into Vault. These files are excluded from our nightly build label and we would (obviously) like them to be promoted each night if the build were successful. We work around promoting by hand through the UI when we have to branch at meaningful points in our development cycle, but it would be nice to have the automated build do this for us.

We've looked at the client API to perhaps script something ourselves but it appears not only is promotion not in the CLC but also it isn't supported through the API. Another vote to include it for future consideration.