So the corruption is rooted in operator error: I misconfigured the Jenkins 
builds configuration. Did a little more reading and it seems that when you 
set the builds directory in the Jenkins configuration to 
${ITEM_ROOTDIR}/builds, this corrects the problem, is now job-specific. It 
would be better if we could possibly pull these aside from the Jenkins 
install location for easier backup and restore purposes, but this will work 
for now.

On Thursday, December 13, 2012 11:08:21 AM UTC-6, mwpowellhtx wrote:
>
> 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