Details
-
Improvement
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
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
- is related to
-
JENKINS-18597 provide the option to ignore system changes
-
- Open
-
-
-
- Open
-
Activity
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 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.
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.
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. 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
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
+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.
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