views:

133

answers:

1

I'm using CC.Net 1.4.4.83 to build my project. I also have some scheduled tasks that independently run builds on the same box using the same working copy. Due some hard-coded paths, we can't use a separate working copy for both build processes. I noticed that sometimes both the scheduled tasks and CC.NET would attempt some sort of SVN operation (maybe an update) at the same time and this would cause the SVN WC to need to be cleaned up. This causes both the scheduled build and the CC.NET build to fail until I manually intervene.

In the hopes of avoiding this problem, I put a FilterTrigger in my CC.NET config file to prevent it from running when the schedules tasks run, but that doesn't seem to have solved the problem.

Does CC.NET still run SVN updates even when it is configured not to build? I would expect the behavior of FilterTrigger to just make it sleep for the duration of the filter period, but the documentation does vaguely indicate that it rejects the builds, not that it doesn't look for them to be triggered. Which is the correct interpretation of the documentation, and if it is the latter, is there another way I can avoid this problem? Will CC.NET fight itself in this same manner if I have multiple projects configured in CC.NET that use the same WC?

FYI, I have seen this question and it doesn't address my issue. Also, suggestions of "just make CC.NET run all your builds", while good and correct, are not useful to me... my company is just transitioning to using CC.NET and the powers that be are unwilling to spend the time modifying all the release-packaging scripts to work with it right now. Thank you very much for your help.

A: 

FilterTrigger does make it sleep during the inactive period. CCNet won't do anything with the project between startTime and endTime. Are you sure the problem isn't caused by something else?

skolima
Well, the logs of the error the first time it happened clearly indicated CCNet was to blame. I assumed the subsequent errors (after I added the FilterTrigger) were from the same cause. Since we stopped the CCNet service the problem has not manifested again. Certainly that's not proof, but it's pretty damning circumstantial evidence :)
rmeador
I still don't know the original cause of this problem, but it did again manifest while CC was disabled, so it was not to blame after all.
rmeador