Jason Jardina, yes that's part of the problem. The current build data solution is stored as a map once per build. The script there will delete all build data to conserve on memory and reduce the bloat. The ultimate issue is not that the single map is that much space but that every build keeps a map of history up to that point. Ultimately the issue is that this scales by N^2. If we have 10k builds, we have roughly N^2 (i know it's slightly less since it's more like n*(n-1)/2 ) number of things being stored in a map.

I firmly believe that the git plugin should be modified to store this data per job in an XmlFile in the job root. This way, we can maintain this history (as you and many others obviously require), while avoiding both the cost-complexity of storing the build data repeatably and of trying to rebuild the data from previous jobs.

This task shouldn't be too difficult, but it does require someone investing time, and unfortunately I don't have time to work on this at $DAYJOB right now, so it's not something I can commit to doing in a timely manner.

Now, one could argue that the git plugin shouldn't be saving data about builds which have been deleted, but that's neither here nor their as clearly people desire this behavior and it's how the plugin has behaved for many years now.

Mark Waite I ran that script you listed and it kicked several, meaning over 50, old builds that had been built previously.  I use regex to scan my repositories by naming convention using git polling.  A build is kicked when commit hash has changed on a regex named branch.  I am glad I ran that on my older code server and not my currently shipping code.  That script is dangerous.  It may solve your problems, but it definitely does not solve mine.  I have to have the build history in order for Jenkins to know what it has built previously, so it doesn't get stuck in a build loop.  That script is like sticking a loaded gun to Jenkins head and pulling the trigger.  Before you tell everyone to run that script and delete their build data, you should warn them they may see unexpected results, exactly like I saw when we updated to git plugin 4.0.0-rc that was accidentally released in the wild last year.

The best solution I found is to only keep 10-20 build history on Jenkins by using Discard Old Builds, log rotation settings.  That lets me keep my current git history, without the history file size getting out of hand and slowing builds/reboots. 

Baptiste Mathus the refactor was reverted because it had unexpected side effects.

My solution involved doing a search/lookup mechanism against all old builds and "rebuilding" the build data every job. This works but slows down significantly once you have a lot of jobs.

I believe a better solution exists using a plugin-specific XML file, so we basically just stop storing the build data per-build and start storing it per-job as a separate file. I've thought about it on-and-off for a while but never got around to trying to implement it.

Unfortunately Baptiste Mathus, the three attempts (two by Nicolas De Loof and one by Jacob Keller ) were unable to significantly refactor BuildData in a compatible fashion. The most recent attempt by Jacob Keller passed multiple months of my testing but showed compatibility issues in the accidental release of git plugin 4.0.0-rc.

The changes were reverted before the release of git plugin 4.0.0.

The git plugin documentation now includes instructions as a system groovy script that removes BuildData. See https://plugins.jenkins.io/git/#remove-git-plugin-buildsbybranch-builddata-script

Mark Waite I think the "BuildData" structure has been heavily refactored isn't it? Should this be closed maybe? Thanks