Thank you guys for the time spent on this issue in explaining how best to approach my deployment/integration strategy. For the record, I was able to write a simple batch script to take the build modifications and push them back to git. The handy thing with git and cruisecontrol together is that you only need to do a simple 'git checkout <branch>' and git automatically takes your changes along for the ride. From there you simply add, commit, and push. Thanks!
On May 31, 8:26 pm, Sam Calder <[email protected]> wrote: > 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?
