We've done something similar (since 1.4.*) - whenever we build a release candidate, we want to create a SVN tag with the build label and then commit the AssemblyInfo.cs changes to the tag... so that any future build from that tag is guaranteed to reproduce the same binaries (only the buildserver service account is permissioned to commit to tags in our SVN). I can't remember the exact script (and even if I could I probably couldn't share it with you anyway - code written on the company's time is the company's property, etc.)... but I recall it was pretty easy to set this up using NAnt and the commandline SVN client: after successful build & test, create a tag, switch the buildserver's working copy to the tag, commit, switch the buildserver's working copy back to the trunk.
We've decided against committing binaries to source control, however if we wanted to we'd most likely use a similar approach as per the above. And presumably you could also do something very similar using Git instead of SVN. It'd probably be easier to reproduce your manual steps as a NAnt script than it would be to write your own CC.net plugin, IMHO - doing it that way also means you won't need to recompile your custom code if you want to upgrade cc.net in future either. Cheers, - Sam. On Mon, May 31, 2010 at 12:56 PM, wintondeshong <[email protected]> wrote: > Hey Daniel, > > Thanks for the explanation of the source control plugin. In addition > to having AssemblyInfo.cs file changes, we have a "libs" folder for > our internal flex and dotnet application frameworks that is > distributed internally to our team. That way each team member can > simply pull the latest on the development branch and run a quick > script to register all of the assemblies for a particular version in > the GAC. So the hope is that new assemblies are built and tested on > the build server (with cruisecontrol) and new builds can easily be > distributed to the rest of the team. Given the current cruisecontrol > tagging/commit approach, we would need to pull the tag when > cruisecontrol reports successful, package up the assemblies, and put > them in the development branch to distribute to the rest of the team > which isn't all that far of from the manual deployment strategy we > presently perform. > > So, from your previous response I gather that this approach isn't > possible with cruisecontrol and even if it is in a later version of > cruisecontrol it doesn't help my current situation. Given all of this, > my follow question is what you think the easiest approach would be to > achieve these results. (ex. download the source for plugin and make > the change for the time being? write an additional task that is run on > success to commit the files the way I want?) > > Thanks for your time! > > > > > On May 30, 9:32 am, Daniel Nauck <[email protected]> wrote: > > Hello, > > > > this is expected behavior. > > CCNet just checkout the remote branch, no merging with the local brach > > is done. > > If you activate the TagOnSuccess feature ist just commits all changes > > and create a new tag. > > And only this tags (all tags) are pushed to the remote repository. > > > > Normally you should have only changes to the AssemblyInfo.cs file or sth > > like that you dont want to have in your branch comitted. > > So what is the reason to commit the build changes also to a branch? > > > > Daniel > > > > Am 30.05.2010 01:50, schrieb wintondeshong: > > > > > So the fix of my previous issue with msysgit 1.7 got me further. Now > > > all builds consistently get triggered via changes to a branch of my > > > choice, tagging is successful, and pushing of those tags back to the > > > remote is good. My next, and last problem (so I hope), is with the > > > pushing of the build modifications. While cruisecontrol is properly > > > listening to the branch of my choice, in this case "development" > > > branch, once a build is successful and tagged. It is not pushing the > > > changes back to the "development" branch but just to a tag out in "Git > > > Space". So I can find the precise tag, but if I go back to the > > > development branch it won't contain any of the latest updated version > > > information or release files. So my question is whether that is > > > expected and if so...is there is a way around that behavior? >
