What forced these projects into "Stopped" status? I haven't been able
to get any answers from the logs. How do we keep our projects from
slipping into this status?
thanks,
cgraham86
what triggers are you using? i believe that if some triggers throw an
exception, it will cause the project to stop the integration loop.
cheers,
owen.
--
Owen Rogers | http://dotnetjunkies.com/weblog/exortech |
CruiseControl.NET - http://ccnet.thoughtworks.com
On Feb 26, 2:01 pm, "Owen Rogers" <exort...@gmail.com> wrote:
We're using perforce and a client spec to check the repository for
changes to the depot. If it detects changes it's supposed to wake up
and build using P4.exe, credentials and the client spec:
<sourcecontrol type="p4">
<view>//mydepot/trunk/...</view>
<executable>D:\Program Files\Perforce\p4.exe</executable>
<client>_Build_Trunk_Continuous_Integration</client>
<user>toolbox</user>
<password>******!</password>
<applyLabel>false</applyLabel>
<autoGetSource>true</autoGetSource>
<forceSync>false</forceSync>
</sourcecontrol>
<triggers>
<filterTrigger startTime="02:00" endTime="02:30">
<trigger type="intervalTrigger" seconds="120" />
</filterTrigger>
</triggers>
We set the filter trigger this way because the Perforce server goes
down for a bit, and we want to avoid trying to do builds during this
time. Also, the logs showed some interesting things...it appears that
all of the projects stopped and CCNet was recycled when some supposed
configuration changes were read in after the ccnet.config file was
updated...related?
> updated...related?- Hide quoted text -
>
> - Show quoted text -
Ok, I think I see a pattern. When we edit the config file in place
without stopping the service (add a project for example) I noticed
that at some point all of the existing projects will slip into
"Stopped" status. I think CCNet is managing this when it reads in
configuration changes as the service is running. Restarting the
windows service brings all of the projects back into "Running"
status. We can select the "Start" button, but in some cases this
initiates an unwanted build right away.
I think we're going to have to be careful with how we manage the
configuration. I think waiting for all of the builds to be dormant
(using the "Stop" button to prevent the schedule from kicking off any
other builds), stopping the service before making any configuration
changes, and then starting it afterwards is the way to go...