Change CCNet workflow to support labels from dvcs source control (Feature #266)
The current workflow on CCNet is:
- Wait for the triggers to awaken.
- Ask the source control system for a list of the modifications since the last build.
- If any modifications were found or if the triggers said "force the build":
- Generate a label for the build.
- Run the prebuild tasks in the order specified, failing the build in case of error.
- Get the source code from the source control system.
- Run the build tasks in the order specified, failing the build in case of error.
- If the repository should be labeled:
- Let the source control system apply the label.
- Run the publisher tasks.
- Go to 1.
As the label is generated before the source checkout we cannot use sth like "git describe" as the label.
We should evaluate to change the workflow to generate the label after the checkout of the source code. (Looks like other build server implementations are also doing this.)See also:
This does not only apply to DVCS, but also to classic centralized ones like SVN. I use a custom labeller that reads the main AssemblyInfo.cs file (specified in config) and returns the AssemblyVersionAttribute value (combined with the change set number) for use as label. Another plugin in pre-build then updates all AssemblyInfos to use this label as AssemblyFileVersionAttribute (to bake the revision into the build for backtracking if something happens).
When using cleanCopy, this only works because the label is created before the old working copy is removed. The initial checkout never has the chance to do this correctly; nor does a failed cleanCopy attempt (ex. when someone locked the folders by opening them in explorer or similar) that requires manual intervention/deletion of the folder.