Why Does CruiseControl.NET need to be restarted after GetCcNetConfigFiles?

Question

CruiseControl.NET service needs to be restarted to pick up changes in the projects configuration files.

I find this very annoying, not sure if it's a bug or it's the way it works.

Is there any way to overcome this issue in people's experience?

Answer 1

I have never experienced this. Whenever I change the configuration files, the CruiseControl.NET service seems to automatically re-read them.

I'm using Version 1.3 of CC.NET.

Update:

In the service's config file (ccservice.exe.config), there is a setting to enable/disable watching the ccnet.config file for changes:

<add key="WatchConfigFile" value="true"/>

Make sure this is set to true.

Answer 2

How are you updating your config files? By hand? Mine always recognizes and adjusts. Is your config file in source control and designed to pull it down and replace the file? This for me requires a kick. How I ended up fixing it was have my project pull it down to a seperate folder. THen I call ccnet.exe -validate on it to make sure it is well formed, then I copy it over ontop of the current config file. CC.NET recognizes the changes and loads in the new config

Exceptions: If cc.net is currently running a project, it will not recognize the changes till that project has completed.

If your ccnet.config has errors, it will not ever recognize the changes and keep running the old version it has stored in memory. (However when CC.NET does restart it will try to parse the error filled config and choke.

Hope this helps!!

Answer 3

Are your projects separated (in a different file) from ccnet.config?

If so, then yes, unless you touch the actual ccnet.config, then you need to restart.

FWIW, we use ENTITY with SYSTEM file reference in ccnet.config for all of our projects, so we're in the same boat. I'm happy to pay the price for easier project maintenance.

Answer 4

Do you mean you are using linked files, that is the ccnet.config file has links to the independent project files.

If so then they are not picked up, it's mentioned in the documentation that it doesn't watch the sub-files.

Internally we have modified our CruiseControl.net so that our ccnet.config is optionally a directory - and we can drop shortcuts to our project config files into that directory. We put watches on the directory, the files or shortcuts in the directory and all of the targets of the shortcuts. That means we have our project config files in ClearCase and just drop a shortcut into the ccnet.config directory.

I've just spent half a day or so moving from 1.2 to 1.4.2 dropping our changes into the new version for our internal use. We don't own our code, our client does and so it has to stay internal :(

Answer 5

There was a bug in CC.Net prior to 1.4.4 if you were using a pre-processor include it did not reload the configuration when an included ccnet.config file was modified.

That was a bug that I reported and it is fixed in CC.Net 1.4.4 and greater.

Also, keep in mind that if a build is running and there is a change to the configuration it will not take place until that build is in an idle state.

Answer 6

to: Alan Mullett or JohnIdol did you ever have time to post this solution of "ccnet.config as directory, where project configs can be dropped". it seems like a very elegant solution to my task. If so, could you please leave a link. Thanks -