Hi
you can save the modifications of a build via the modification writer task http://confluence.public.thoughtworks.org/display/CCNET/Modification+Writer+Task and you can read them back in via the modification reader task http://confluence.public.thoughtworks.org/display/CCNET/Modification+Reader+Task maybe this will help a bit with kind regards Ruben Willems On Fri, Jan 16, 2009 at 12:19 PM, [email protected] < [email protected]> wrote: > > Hi, > I have been given the task of automating the build process for the > place I work at. I got the build and unit-tests etc working, also I > have a build and deployment to a test server automated (triggered > using cruisecontrol.net). My next step is to clean up how we patch our > code changes for testing. Currently the source used for build and > deployment to test servers is on a network share, but it is becoming > increasingly hard to track what files have changed and why, then a > nightmare to remove changes (say temporarily if someone goes on > holiday). After toying with a few ideas people seem to like the idea > of a process that does the following using .patch files. > > 1. Unpatch any currently patched patches. > 2. SVN update (so now we are at the point of whats currently in SVN). > 3. Patch any patches (more useful to see why a code change fails from > perspective of making the code change to current SVN code rather than > trying to add new code to previous svn revision modified with > patches ... if you get me. I did toy with idea of having a seperating > testing repoistory which receives same commits as official repo + > testing patchings therefore keeping the modifications section but that > seemed a little over kill and people didn't like it). > 4. Build. > 5. Deploy. > > This way we can still have a read only share showing the state of the > code after an svn update and patching. Unfortunately because you can't > perform tasks before the source control block the svn update is > handled by another nant task. This is removing the nicely formatted > modifications section in our logs. While I don't think anyone here > uses that section, it would be nice to still have it there if > possible, so I am open for suggestions on how to do this. One idea I > looked into was coding my own sourcecontrol block that inherits the > SVN source control block and includes the patching process in it, > however then I don't see how to output patching errors to the error > output log so I still lose (but more so than losing the modifications > section). The only other way I see of doing it is trying to match the > xml output in the logs for the modification section that > cruisecontrol.net uses ready for the web dashboards xsl parsing for > the frontend (which I am hoping someone else has done maybe???). Any > suggestions?? > > Thanks in advance. >
