Status: Resolved (View Workflow)
When working with many short-lived feature branches, Jenkins can start to eat up a lot of disk space by leaving old workspaces around from old builds.
This seems to be especially true with the Pipeline Multibranch Plugin. When that plugin deletes the job for a branch when the branch is deleted, it should simultaneously clean up any of the workspaces created for that branch job (e.g. "feature-foo", "feature-foo@2", "feature-foo@3", etc).
JENKINS-2111 removing a job (including multibranch/org folder branches/repos) does not remove the workspace
- is related to
JENKINS-22240 Workspace folder not renamed/deleted when renaming job
Would be nice to have a configurable trigger "onBranchDelete" to execute custom cleaning scripts like the "Post-build Actions" in normal jobs.
In my workflow, I'm deploying feature branches code and database to a testing environment which should be cleaned once the feature branches have been merged and deleted.
We have a large, multi-gigabyte repository, and this bug is repeatedly causing us to either have to go in and manually clean out old branches, or giving test failures because hundreds of gigabytes of space are being taken up in a short time due to the multiple checkouts.
We are also experiencing this. It seems to cause issues at the most inconvenient time. (Of course when would it ever be convenient). We have temporarily set up a very conservative cron style jenkins job to clean out the jobs in the wee hours of the morning, but that could potentially cause problems down the line. Would like to keep the cleanup in house on a per job basis.
I think this is actually a more general core issue: Job.delete (or some associated ItemListener.onDeleted should proactively delete any associated workspaces it can find on any connected nodes. WorkspaceCleanupThread as currently implemented is not going to find them.
JENKINS-22240 is very similar; probably both could and should be fixed together.
YES! Actually I want to limit a multi-branch pipeline to only keep the 3 most used branches around (like master, and two currently used feature branches).
A "Number of most frequently used branches to keep" setting would be awesome IMO.