tag:studios.thoughtworks.com,2008:/2007/11/8/configuring-cruisecontrol-the-cruisecontrol-way/comments Mephisto Noh-Varr 2008-06-03T15:46:52Z Julian Simpson tag:studios.thoughtworks.com,2007-11-08:993:1088 2008-06-03T08:07:00Z 2008-06-03T08:07:00Z Hi Ajay, You could specify multiple entries in the modification set: http://cruisecontrol.sourceforge.net/main/configxml.html#svn Mail me at the email address above your post if you want to go into more detail on this. Cheers Julian. Ajay tag:studios.thoughtworks.com,2007-11-08:993:1086 2008-06-02T23:59:18Z 2008-06-02T23:59:18Z Hi Julian This is really great idea. I have a question regarding setting the desired directories only in the config file , so that any change in this directory doesnt kick thebuild process .. say for example ..i have specified in the config file as any change under /LTP project ..kicks in build process but now i decide there is a directory with docs and if anything changes there the build shouldnt kick in ..is it possible to exclude dirs and the build doesnt kick in ? thanks Julian Simpson tag:studios.thoughtworks.com,2007-11-08:993:1078 2008-05-22T14:18:11Z 2008-05-22T14:18:11Z John, Can you email me some more of the output please? medic (at) build-doctor {dot} com Thanks. Best Julian. John tag:studios.thoughtworks.com,2007-11-08:993:1077 2008-05-21T01:24:23Z 2008-05-21T01:24:23Z I implemented this but was frustrated to find how strict the validation rules were. I have "<svnbootstrapper localworkingcopy='projects/${project.name}' />" in my project. This is causing a validation error to be thrown: "Error validating cruisecontrol config: 'localWorkingCopy' must be an existing directory." I guess i could rename my project to better coincide with the expected output, or create dummy directories (very ugly). how would you propose getting around this? I also have <svn localworkingcopy='projects/${project.name}/Vinoshipper' /> and suspect this will be a problem as well. David Pattinson tag:studios.thoughtworks.com,2007-11-08:993:995 2007-12-06T06:07:00Z 2007-12-06T06:07:00Z It's nice to be able to test that config file before you check it in too, in cases where you're trying to do something tricky and/or the build time is long. In that case it can help to extract environment specific parameters (for example the spam list for breakages, or the database schema name) into a properties file that you merge into the config as part of pushing it onto the target environment. This way you can have a seperate set of properties for testing your config file on a local box, and run less risk of accidentally breaking the build. Nicolás Cornaglia tag:studios.thoughtworks.com,2007-11-08:993:994 2007-11-21T08:46:00Z 2007-11-21T08:46:00Z Nice touch. I never thought about config files...