Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-15190

Implement "max builds to show" as a global config

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • robot-plugin
    • None

      With over e.g. 200+ builds the generation of trend graphs for duration and test result takes several seconds.

      As seen from discussion below, the best solution would be to implement "max builds to show" option also in global config. It should be decided how global configs and job configs interact with each other.

      Also disabling the graph altogether can be considered.

          [JENKINS-15190] Implement "max builds to show" as a global config

          jpiironen created issue -
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 145912 ] New: JNJira + In-Review [ 176476 ]

          Alex Gray added a comment -

          Could be related to: https://issues.jenkins-ci.org/browse/JENKINS-15818

          Alex Gray added a comment - Could be related to:  https://issues.jenkins-ci.org/browse/JENKINS-15818

          Dirk Richter added a comment - - edited

          Analysis of output.xml on 200+ builds means a lot of cpu, which seems to be normal for me!

          I see 3 possible solutions:
          1. Did you consider to use parameter "Max builds" (e.g. set to 20)? Then the last 20 builds are shown only.
          2. Did you consider to automatically discard old builds? You can configure amount of days of amount of builds to keep in project configuration.
          3. Currently the image generation is on demand and starts, when user requested it via frontend. Robot-Plugin could precompute such images when the build is finish.

          Dirk Richter added a comment - - edited Analysis of output.xml on 200+ builds means a lot of cpu, which seems to be normal for me! I see 3 possible solutions: 1. Did you consider to use parameter "Max builds" (e.g. set to 20)? Then the last 20 builds are shown only. 2. Did you consider to automatically discard old builds? You can configure amount of days of amount of builds to keep in project configuration. 3. Currently the image generation is on demand and starts, when user requested it via frontend. Robot-Plugin could precompute such images when the build is finish.
          Tatu Kairi made changes -
          Priority Original: Major [ 3 ] New: Minor [ 4 ]

          Aaron Miller added a comment -

          Hello,

          Would you consider adding an option to disable the trend graph either in the global plug-in config and/or per job?

          The suggested solutions are not ideal for us:

          1. This requires each user to change that parameter, individually on each job. Also it looks like the setting is stored in their browser cache, correct? So if that is cleared they will need to do it again. And users who don't bother are potentially using up a lot of CPU cycles on our master any time they view a project.
          2. While this would work, it feels a bit like the tail wagging the dog. We retain those builds for business reasons, removing them to improve performance of a feature we don't need is not a direction we'd like to go.
          3. While better than the current situation, this is still potentially using a lot of CPU cycles on our master for a feature that we aren't interested in.

          Thank you!

           

          Aaron Miller added a comment - Hello, Would you consider adding an option to disable the trend graph either in the global plug-in config and/or per job? The suggested solutions are not ideal for us: This requires each user to change that parameter, individually on each job. Also it looks like the setting is stored in their browser cache, correct? So if that is cleared they will need to do it again. And users who don't bother are potentially using up a lot of CPU cycles on our master any time they view a project. While this would work, it feels a bit like the tail wagging the dog. We retain those builds for business reasons, removing them to improve performance of a feature we don't need is not a direction we'd like to go. While better than the current situation, this is still potentially using a lot of CPU cycles on our master for a feature that we aren't interested in. Thank you!  
          Aleksi Simell made changes -
          Assignee Original: jpiironen [ jpiironen ] New: Aleksi Simell [ aleksisimell ]

          Aleksi Simell added a comment -

          Hi aaronm

          We could definitely look on a solution to have a "max builds to show" in global configs, potentially overwritable per job. This feature is already in place for X-axis label, so doing that for the amounts of builds to show should be doable.

          Aleksi Simell added a comment - Hi aaronm We could definitely look on a solution to have a "max builds to show" in global configs, potentially overwritable per job. This feature is already in place for X-axis label, so doing that for the amounts of builds to show should be doable.

          Aaron Miller added a comment -

          Hi Aleksi,

          It would be nice if the graph could be disabled totally. If "max builds to show" is set to a low value to avoid using much CPU, the graph isn't all that useful (but is still using some CPU). Not a huge deal though.

          Thanks!

          Aaron Miller added a comment - Hi Aleksi, It would be nice if the graph could be disabled totally. If "max builds to show" is set to a low value to avoid using much CPU, the graph isn't all that useful (but is still using some CPU). Not a huge deal though. Thanks!
          Aleksi Simell made changes -
          Summary Original: Creation of trend graphs is slow on large number of builds New: Implement "max builds to show" as a global config

            aleksisimell Aleksi Simell
            jpiironen jpiironen
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: