Hello,

I have half a dozen or so jobs configured to run and I am finding that 
Jenkins build history is becoming very corrupt. We're running 1.492 in a 
Windows 7 Ultimate environment.

Here's what I am experiencing:

   - From time to time my executor threads will just completely die. It 
   usually takes pulling the build history aside and letting Jenkins start 
   afresh to recover from this. One of the issues appears to be array 
   indexing, frequently thinking it has an invalid array index. Apparently 
   also a known issue for quite some time from other posts I've read.
   - I've started up the system once again and now I am finding that the 
   build history is apparently really confused. I have one disabled job and 
   all the others were building yesterday with valid history.
   
How can any snafus like this be happening? I mean, did the designers of 
these systems and subsystems consider that a build environment would have 
use cases involving multiple independently scheduled jobs?

The other option we can consider is to not keep a running build history at 
all, particularly in a matrix build environment like we're got running. 
History is nice and to show a healthy build history track record, but is 
not as important as long as we can capture artifacts like generated 
documents, NuGet packages, installers, and the like.

I hate to say it, but if Jenkins is going to be this unstable, I wonder if 
I don't give Hudson a try (again). Or even spend the energy to configure a 
CruiseControl.NET. But the first thing I want to consider is 86'ing the 
build history if it's going to cause that many problems.

Any others with thoughts? Questions, concerns, suggestions?

Regards,

Michael

Reply via email to