• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • junit-plugin
    • None
    • core: 1.565.3 LTS
      plugin: 0.6.0

      I had trend history, then aborted two builds (run job and press abort), after it trend history graph become clear.
      After 2 builds graph filled back with 2 results (but before abort results still doesn't appeared).

          [JENKINS-25340] lost trend history after skipping build

          I am using matrix (multi configuration) projects with filters to build only a subset of all the possible configurations.
          These filters are dynamic and change from one build to another, so some configurations are sometimes built and sometimes not.
          This causes "holes" in the history of the configurations, preventing the test result trend to display the entire history for a given configuration.

          For example:
          Matrix can build CONF1 and CONF2
          Build #1 is CONF1
          Build #2 is CONF1
          Build #3 is CONF2
          Build #4 is CONF2
          Build #5 is CONF1
          Build #6 is CONF1
          => CONF1 history is #1 #2 #5 #6, CONF2 history is #3 #4, and CONF1 test result trend only shows #5 #6

          I would appreciate any suggestions to get all the builds for the configuration in the test result trend...

          Jean-Luc Raffin added a comment - I am using matrix (multi configuration) projects with filters to build only a subset of all the possible configurations. These filters are dynamic and change from one build to another, so some configurations are sometimes built and sometimes not. This causes "holes" in the history of the configurations, preventing the test result trend to display the entire history for a given configuration. For example: Matrix can build CONF1 and CONF2 Build #1 is CONF1 Build #2 is CONF1 Build #3 is CONF2 Build #4 is CONF2 Build #5 is CONF1 Build #6 is CONF1 => CONF1 history is #1 #2 #5 #6, CONF2 history is #3 #4, and CONF1 test result trend only shows #5 #6 I would appreciate any suggestions to get all the builds for the configuration in the test result trend...

          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.

          Javier Delgado added a comment - 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.

          David Potts added a comment -

          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.

          David Potts added a comment - 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 added a comment - - edited

          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 added a comment - - edited 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.

          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.

          Andrew Martignoni III added a comment - 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.

          Jesse Glick added a comment -

          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.

          Jesse Glick added a comment - 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 added a comment -

          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.

          David Potts added a comment - 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.

          Jesse Glick added a comment -

          add comments indicating that this is still an issue

          Use the Vote for this issue link.

          Jesse Glick added a comment - add comments indicating that this is still an issue Use the Vote for this issue link.

          Ilya Ilba added a comment -

          Could somebody please try my fix (incremental build here). Cannot verify it myself as I'm stuck with the old version of jenkins which is incompatible with the latest junit.

          Ilya Ilba added a comment - Could somebody please try my fix (incremental build here ). Cannot verify it myself as I'm stuck with the old version of jenkins which is incompatible with the latest junit.

          This seems like it was fixed ages ago, can we close this now?

          Andrew Martignoni III added a comment - This seems like it was fixed ages ago, can we close this now?

            Unassigned Unassigned
            integer Kanstantsin Shautsou
            Votes:
            30 Vote for this issue
            Watchers:
            31 Start watching this issue

              Created:
              Updated: