[JIRA] [junit-plugin] (JENKINS-25340) lost trend history after skipping build

In my use case, I perform jobs cleanups so that unneeded-unwanted jobs (self aborted ones) wont pollute the history. This impacts the jUnit trend.

This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)

david.potts@aveillant.com (JIRA)

unread,

Oct 13, 2016, 10:06:06 AM10/13/16

to jenkinsc...@googlegroups.com

David Potts commented on

I had assumed in the past that I was just seeing a glitch in my setup when the 'test result trend' graph "went funny".

However, I have had a spate of build failures more recently that caused me to 'tidy up' and delete failed builds for which the testing simply was not relevant - and now can only see 2 or 3 builds in the trend chart. Not at all useful.

And yes, I have also seen memory issues in the past, and traced it back to the way the trendChart 'recursively' read the Junit XML logs (or rather, it looked that way from the stack trace), rather than linearly counting back the jobs, and simply culling out the necessary data. From a data processing point of view, the same amount of file reading is performed; but one is locking up data on the stack, the other has the opportunity of getting rid of data not pertinent to the job in hand [ oh, and feel free to tell me I'm nowhere near correct here; I didn't look at the code in detail, merely filled in the blanks from what I saw in the stack trace combined with a very cursory glance at the code ]

I find the 'test result trend' graph to be incredibly useful for what I do, and can't believe that it has been so compromised for so long.

daniil.ivanov@gmail.com (JIRA)

unread,

Nov 11, 2016, 5:20:11 AM11/11/16

to jenkinsc...@googlegroups.com

Daniil Ivanov commented on

This is caused by having non-sequential build numbers in build directory for your job jenkins/jobs/$

{JOB_NAME}/builds.
For example, you have builds 1 2 3 5 6 7, then trend results will show only builds 5 6 7 because build 4 is missing.
To workaround this I've created a script:

{{#!/bin/sh

max=3700
last_dir=1
for cur_dir in $(seq 1 $max)
do
if [ -d "$cur_dir" ]; then
if [ $(expr $cur_dir - $last_dir) -gt 1 ]; then
new_dir=$(expr $last_dir + 1)
echo moving $cur_dir to $new_dir
mv $cur_dir $new_dir
last_dir=$new_dir
else
last_dir=$cur_dir
fi
fi
done
}}

which moves builds down to fill the gaps. After running the script you still need to edit jenkins/jobs/${JOB_NAME}

/nextBuildNumber to place a new number and restart Jenkins. Then after next successful build trend result will be complete again.

daniil.ivanov@gmail.com (JIRA)

unread,

Nov 11, 2016, 5:20:16 AM11/11/16

to jenkinsc...@googlegroups.com

Daniil Ivanov edited a comment on

This is caused by having non-sequential build numbers in build directory for your job jenkins/jobs/${JOB_NAME}/builds.
For example, you have builds 1 2 3 5 6 7, then trend results will show only builds 5 6 7 because build 4 is missing.
To workaround this I've created a script:

{ color:#205081} { color:red} #!/bin/sh

max=3700
last_dir=1
for cur_dir in $(seq 1 $max)
do
  if [ -d "$cur_dir" ]; then
    if [ $(expr $cur_dir - $last_dir) -gt 1 ]; then
      new_dir=$(expr $last_dir + 1)
      echo moving $cur_dir to $new_dir
      mv $cur_dir $new_dir
      last_dir=$new_dir
    else
      last_dir=$cur_dir
    fi
  fi
done

{color } {color }

which moves builds down to fill the gaps. After running the script you still need to edit jenkins/jobs/${JOB_NAME}/nextBuildNumber to place a new number and restart Jenkins. Then after next successful build trend result will be complete again.

andrew.j.martignoni-iii@boeing.com (JIRA)

unread,

Nov 14, 2016, 8:17:03 AM11/14/16

to jenkinsc...@googlegroups.com

Andrew Martignoni III commented on

The best fix would be to use information from Jenkins core to iterate rather than the current method involving consecutive numbers. If there really is no alternative to using the file system directly, then I suggest iterating over all numbers from 1 to (the contents of nextBuildNumber), or perhaps in reverse, stopping after the max number of builds to graph is reached. Is there anyone working on the plugin who could take a look at this? I haven't seen the code, so I can't be more specific or supply a patch.

jglick@cloudbees.com (JIRA)

unread,

Nov 15, 2016, 9:19:01 AM11/15/16

to jenkinsc...@googlegroups.com

Jesse Glick commented on

Pointless to add comments here unless you understand the implementation of RunList and are able to evaluate whether the current core API suffices to implement this here or whether the core API needs to be extended.

david.potts@aveillant.com (JIRA)

unread,

Nov 15, 2016, 11:02:02 AM11/15/16

to jenkinsc...@googlegroups.com

David Potts commented on

With respect, Jesse, I'm hoping that it's not pointless to add comments indicating that this is still an issue - and that some of us are not happy with having to make use of workarounds for functionality that should be fixed within Jenkins itself.
Not having this fixed is not enough to force me to move from Jenkins, obviously; but it does make me question how much testing is performed (because this did work at one point in time), and therefore how much reliance I can place on my use of Jenkins.

jglick@cloudbees.com (JIRA)

unread,

Nov 15, 2016, 11:41:03 AM11/15/16

to jenkinsc...@googlegroups.com

Jesse Glick assigned an issue to Unassigned

Jenkins /

lost trend history after skipping build

Change By:	Jesse Glick
Assignee:	Jesse Glick

jglick@cloudbees.com (JIRA)

unread,

Nov 15, 2016, 11:41:03 AM11/15/16

to jenkinsc...@googlegroups.com

Jesse Glick commented on

add comments indicating that this is still an issue

Use the Vote for this issue link.

ilya.ilba@gmail.com (JIRA)

unread,

Aug 21, 2019, 4:03:03 PM8/21/19

to jenkinsc...@googlegroups.com

Ilya Ilba commented on