• Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-plugin
    • None

      We run a fairly high load Jenkins install with 16 gb of ram, 8 cores and 47 executors (none on the master). One of our main git repositories is very large, containing about 60K files and receives multi-hundreds of commits per day. As a result the process of generating change logs is very cpu and memory intensive and we often have upwards of 20 or more such builds in flight at any one time. This results in several such change logs being generated at the same time, often resulting a heap errors on the master. To Jenkins credit, it survives these w/o crashing. The builds fail though and get retried, only adding to the load.

      However, such extremely large change logs are fairly useless and we can generate them after the fact any way when we really do need them. Therefore it would be very advantage for use to be able to turn of change log generation either system-wide or ideally, on a job by job basis.

      Another reason for implementing this feature is that these changes logs (some of them are half a gig) needlessly use up storage on the master. We have gone so far as to implement a cleanup script on a cron job that just goes through and deletes the change logs.

          [JENKINS-32222] Disable SCM Change Logs

          Daniel Beck added a comment -

          subversion-plugin?

          Daniel Beck added a comment - subversion-plugin ?

          Owen Wood added a comment -

          danielbeck my brain saw SCM and converted to SVN Fixed component.

          Owen Wood added a comment - danielbeck my brain saw SCM and converted to SVN Fixed component.

          Mark Waite added a comment - - edited

          If it truly is change log generation which causes the problem, then you might try an experiment of computing the change log against a base version, and list that base version as "HEAD". The change log against "HEAD" should always be empty (I think), so should compute very quickly and with low overhead.

          I fear that the problem may be related to BuildData (rather than change log). If using HEAD as the basis for change log calculation does not resolve the problem, then it may indicate the much larger challenge that too much information is being carried in BuildData. Unfortunately, that is a very hard problem to solve.

          Mark Waite added a comment - - edited If it truly is change log generation which causes the problem, then you might try an experiment of computing the change log against a base version, and list that base version as "HEAD". The change log against "HEAD" should always be empty (I think), so should compute very quickly and with low overhead. I fear that the problem may be related to BuildData (rather than change log). If using HEAD as the basis for change log calculation does not resolve the problem, then it may indicate the much larger challenge that too much information is being carried in BuildData. Unfortunately, that is a very hard problem to solve.

            Unassigned Unassigned
            owood Owen Wood
            Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: