1

I have a CruiseControl.NET powered build server and an exec task that increments assembly version of the project before building it. I was wondering, was there a way (a CruiseControl.NET task I don't know about) to submit that modified file back to SVN?

I need it so when the setup projects are built manually (I am using msbuld so those aren't built continuously) all the build files will have the correct assembly versions on deployment. Oh and if someone knows how to build setup & deployment projects on a build server without Visual Studio installed, I'm dying to know!

EDIT: Thanks to Jonathan Stanton the update now works, however it creates another problem... The build server now loops (on change it updates assembly version and commits the file. This caouses the onModify trigger to fire so it updates assembly version and commits the file...).

What can I do so it won't loop? Can I add an update SVN task? Will that help?

David Božjak
  • 16,887
  • 18
  • 67
  • 98
  • I have tried to add a update task after the commit task, however it doesn't help, it is still finding modifications on every run. – David Božjak Jul 21 '10 at 12:14
  • I tried setting the SVN to use revisionNumbers, thinking since I am updating my working directory, this will prevent it from building, however it is still trigering on every interval... – David Božjak Jul 21 '10 at 12:38

4 Answers4

2

The following task will commit back the a file in to the source repo. 

<exec executable="svn.exe">          
    <buildArgs>commit -F <file you want to commit back> --username USER --password PASS --no-auth-cache --non-interactive --message 'CruiseControl.net build %CCNetLabel%'</buildArgs> 
    <buildTimeoutSeconds>10</buildTimeoutSeconds>
</exec>

The following links may be of use:

I hope that this helps

Jonathan

EDIT

There is another way to do this and that is to allow CC.NET to set the build version in the DLL. There is a walkthrough on how to do this at Damir's Corner entitled Setting Up SVN and CC.NET for .NET Development

Jonathan Stanton
  • 2,531
  • 1
  • 28
  • 35
  • I am just wondering if this won't cause the build trigger again and thus create an infinite loop of incrementing and building the same project all over again? – David Božjak Jul 21 '10 at 10:22
  • This indeed does loop the build server. A full build now happens every 5 minutes (With an increased version). What can I do so the task won't trigger CruiseControl.NET build? – David Božjak Jul 21 '10 at 10:50
  • What is the file that you are committing? If it is the dll then could you create a new branch or new repo that contains just this file. You would then map that branch / repo to a new directory, have a task that copied the dll/file to that directory and then run the commit on that file. Your other projects would just then have to monitor that new branch/repo for that file. – Jonathan Stanton Jul 21 '10 at 11:48
  • I am commiting the assemblyversion.cs file on every project (that was modified) – David Božjak Jul 21 '10 at 12:03
  • Rekreativc - Does the Damir's Corner blog help you at all? – Jonathan Stanton Jul 26 '10 at 18:04
  • You can configure a Filtered Source Control block to ignore certain files/extensions. This way the commit will not kick off another build. I've got an example at work but the documentation on the Thoughtworks site should point you in the right direction. – DilbertDave Jul 29 '10 at 15:42
2

There's another answer on stackoverflow about how to cfg cc to avoid the build cycle: How to checkin code during the build

Community
  • 1
  • 1
gap
  • 2,766
  • 2
  • 28
  • 37
0

This question may help.

I gave up on the setup and deployment projects because of the VS dependency.

Community
  • 1
  • 1
devstuff
  • 8,277
  • 1
  • 27
  • 33
0

In the post on my blog which Jonathan linked to in his answer I described my setup which doesn't do any commits during the build process. Instead of increasing the build number during the build I just use the revision number from Subversion. I prefer it this way because based on the build number I can easily retrieve the sources that where used to make the build.

Ths works great in my case where all the builds are done on CruiseControl.NET. Building setups manually is more tricky in this case because the files in Subversion don't have the correct build number. You could circumvent this problem by using the already modified files from CruiseControl.NET build and use them to build your setup. Or you could just build the setup continuously as well.

If this doesn't work for you, you should take the Filtered Source Control Block path suggested by DilbertDave. Just put your AssemblyInfo.cs file (or any other files you modify in the build process) in the exclusionFilters to get rid of the build loop.

Damir Arh
  • 17,637
  • 2
  • 45
  • 83