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

Allow to commit SYSTEM-modified files only periodically

    XMLWordPrintable

Details

    Description

      After discussion on JENKINS-18187, it appears to be a nice feature to not commit SYSTEM-modified files "just after modification"

      I imagine :

      • A checkbox saying "activate delayed and periodic SYSTEM commit every XXX hours" (XXX would be a user input).
      • When a SYSTEM modification is detected, 2 possibilities :
        • There is already a recent commit which have been made by SYSTEM : on this case, we will queue every modified files in a List<Path>, which will grow until next SYSTEM commit
        • Latest commit was made a long time ago (period > XXX hours) : in that case, we take the List<Path> and commit it
      • When a non-SYSTEM modification is detected, we commit it with the desired user, and remove changeset's paths from the SYSTEM's List<Path> queue
        Only drawback here, will be we could commit things made both by SYSTEM and user modifications

      If you think about better implementation for this feature, don't hesitate to share your POV

      Attachments

        Issue Links

          Activity

            jklap Jason Klapste added a comment -

            I'd second this-- we have several scripts that run pre and post jobs that make changes to the job configs-- if the commit was delayed where would have been no change to commit to svn. Currently we get about 30 commits back-to-back followed by another 30 commits post job. Getting messy

            jklap Jason Klapste added a comment - I'd second this-- we have several scripts that run pre and post jobs that make changes to the job configs-- if the commit was delayed where would have been no change to commit to svn. Currently we get about 30 commits back-to-back followed by another 30 commits post job. Getting messy
            axeda_clint clint axeda added a comment -

            I'll add a +1 here. I need something along these lines too. i disabled the disk usage plugin because we have a significant number of builds (100 ish) and each time it modifies a config it turns into a commit to svn. this results in hundreds of commits a day just to update the disk usage which is really terrible.

            axeda_clint clint axeda added a comment - I'll add a +1 here. I need something along these lines too. i disabled the disk usage plugin because we have a significant number of builds (100 ish) and each time it modifies a config it turns into a commit to svn. this results in hundreds of commits a day just to update the disk usage which is really terrible.

            @clint In your case, I think you could be interested in JENKINS-19659 too

            Including hudson*.xml files by default is maybe a bad idea as well.

            fcamblor Frédéric Camblor added a comment - @clint In your case, I think you could be interested in JENKINS-19659 too Including hudson*.xml files by default is maybe a bad idea as well.
            axeda_clint clint axeda added a comment -

            well for me the config.xml of the jobs was the killer. the disk usage plugin adds what appears to be a timestamp everytime it calculates (which seemed to be with each build). so 50+ jobs building 10 times a day turned into 500 commit messages which was a lot of noise...

            being able to filter out 'system' commits would be quite handy as all these changes were made by 'the system'. or queing up system commits to a daily (or whenever a real person makes a real change to the job).. anything

            axeda_clint clint axeda added a comment - well for me the config.xml of the jobs was the killer. the disk usage plugin adds what appears to be a timestamp everytime it calculates (which seemed to be with each build). so 50+ jobs building 10 times a day turned into 500 commit messages which was a lot of noise... being able to filter out 'system' commits would be quite handy as all these changes were made by 'the system'. or queing up system commits to a daily (or whenever a real person makes a real change to the job).. anything
            trbaker Trevor Baker added a comment -

            +1 The Amazon EC2 Plugin updates config.xml each time is deploys and terminates ec2 instances for jenkins nodes. We are terminating instances on an idle timer and don't want transient nodes triggering commits.

            trbaker Trevor Baker added a comment - +1 The Amazon EC2 Plugin updates config.xml each time is deploys and terminates ec2 instances for jenkins nodes. We are terminating instances on an idle timer and don't want transient nodes triggering commits.

            People

              Unassigned Unassigned
              fcamblor Frédéric Camblor
              Votes:
              3 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated: