Project configuration says one thing, yet running service does another
1 view
Skip to first unread message
Brendan Crosser-McGay
Aug 24, 2008, 7:15:02 PM8/24/08
to ccnet...@googlegroups.com
I run CC.Net so that I can update the config via source control and CC.Net monitors that location, if it changes, it updates, and then CC.Net's own config is under source control. I'm aware that this is a known and tested method of maintaining CC.Net configurations.
When I was working with a recent build of CC.Net (also happened with previous builds, but I digress) I had all my projects setup and going and happy. Then I decided to make use of the spiffy new config-builder preprocesser thing so that I could have lots of projects that all use a standard configuration. So, I managed to set up a bunch of my projects using the config-builder stuff without too much trouble. After making the changes and checking them in, CC.Net picked up the changes to it's own config file and updated the config file on the computer running CC.Net. I go into the web interface and click the "project configuration" link to make sure that the config I setup was what is currently running, and sure enough it was.
However, to my chagrin, I noticed that when I would check something in one project, it would trigger all of the other projects. Nomrally these other projects wouldn't build because of excludeFilters setup in the config. So, I played around with it for a bit, and I was unable to fix it. I had changed the configuration for multiple projects to include config-builder xml elements to reduce the amount of code in my config file and standardize the project configurations for all my projects.
The most bizarre thing I've found was that after not being able to fix this problem remotely via checking in new config files that are then populated back into the cc.net machine, I found that simply re-starting the CC.Net service would make the config that the web interface was showing, match exactly what the service was actually using.
-Brendan
When I was working with a recent build of CC.Net (also happened with previous builds, but I digress) I had all my projects setup and going and happy. Then I decided to make use of the spiffy new config-builder preprocesser thing so that I could have lots of projects that all use a standard configuration. So, I managed to set up a bunch of my projects using the config-builder stuff without too much trouble. After making the changes and checking them in, CC.Net picked up the changes to it's own config file and updated the config file on the computer running CC.Net. I go into the web interface and click the "project configuration" link to make sure that the config I setup was what is currently running, and sure enough it was.
However, to my chagrin, I noticed that when I would check something in one project, it would trigger all of the other projects. Nomrally these other projects wouldn't build because of excludeFilters setup in the config. So, I played around with it for a bit, and I was unable to fix it. I had changed the configuration for multiple projects to include config-builder xml elements to reduce the amount of code in my config file and standardize the project configurations for all my projects.
The most bizarre thing I've found was that after not being able to fix this problem remotely via checking in new config files that are then populated back into the cc.net machine, I found that simply re-starting the CC.Net service would make the config that the web interface was showing, match exactly what the service was actually using.
-Brendan
Ross Patterson
Aug 26, 2008, 3:46:14 PM8/26/08
to ccnet...@googlegroups.com
On Sun, Aug 24, 2008 at 19:15, Brendan Crosser-McGay <ver...@gmail.com> wrote:
After making the changes and checking them in, CC.Net picked up the changes to it's own config file and updated the config file on the computer running CC.Net. I go into the web interface and click the "project configuration" link to make sure that the config I setup was what is currently running, and sure enough it was.
...
The most bizarre thing I've found was that after not being able to fix this problem remotely via checking in new config files that are then populated back into the cc.net machine, I found that simply re-starting the CC.Net service would make the config that the web interface was showing, match exactly what the service was actually using.
Ross
Ross Patterson
Aug 26, 2008, 3:50:47 PM8/26/08
to ccnet...@googlegroups.com
On Sun, Aug 24, 2008 at 19:15, Brendan Crosser-McGay <ver...@gmail.com> wrote:
However, to my chagrin, I noticed that when I would check something in one project, it would trigger all of the other projects. Nomrally these other projects wouldn't build because of excludeFilters setup in the config. So, I played around with it for a bit, and I was unable to fix it.
It sounds like we're going to need to see your CCNET logfile.
I had changed the configuration for multiple projects to include config-builder xml elements to reduce the amount of code in my config file and standardize the project configurations for all my projects.
That shouldn't have had any impact, other than the possibility that the config file didn't get processed the way you thought it would. The config-builder runs completely separately from the configuration reader, and creates an actual fully-expanded XML document (albeit one in memory instead of on disk) that is then read by the configuration reader.
Ross
Brendan CM
Aug 26, 2008, 4:12:08 PM8/26/08
to ccnet-user
Sorry my description is a bit vague, it's not contradictory, I just
jumped around a bit. Here's the order it happened in
1. CCnet service running with build 1.4.0.3554, setup to trigger a
config update from source control.
2. I change config on multiple projects with config-builder code.
3. According to CCtray CCnet config is updated successfully.
4. I go to web dashboard and click the (project name) > Project
Configuration link to verify the config was updated
5. After a quick inspection, I confirm that the config looks like the
one I want.
6. Check in code for project A.
7. Project A, B, C and D all are triggered to build, even though
according to configuration on web dashboard, only project A should
trigger.
8. I'm unable to find any problems with the config file in source
control or the web dashboard.
9. I restart the CCnet service on the build machine.
10. I check the web dashboard config again, no changes.
11. I check in code for project A.
12. Only Project A is triggered to build.
On Aug 26, 12:46 pm, "Ross Patterson" <ross.patter...@gmail.com>
wrote:
jumped around a bit. Here's the order it happened in
1. CCnet service running with build 1.4.0.3554, setup to trigger a
config update from source control.
2. I change config on multiple projects with config-builder code.
3. According to CCtray CCnet config is updated successfully.
4. I go to web dashboard and click the (project name) > Project
Configuration link to verify the config was updated
5. After a quick inspection, I confirm that the config looks like the
one I want.
6. Check in code for project A.
7. Project A, B, C and D all are triggered to build, even though
according to configuration on web dashboard, only project A should
trigger.
8. I'm unable to find any problems with the config file in source
control or the web dashboard.
9. I restart the CCnet service on the build machine.
10. I check the web dashboard config again, no changes.
11. I check in code for project A.
12. Only Project A is triggered to build.
On Aug 26, 12:46 pm, "Ross Patterson" <ross.patter...@gmail.com>
wrote:
Reply all
Reply to author
Forward
0 new messages