We current have the following Release workflow:
Every few days or weeks a new release-branch is created. This branch is then built and artifacts get archived. We usually keep the release-Branches over a year, so that we can compare any changes.
We also use the global build discarder with "days to keep artifacts"=90.
However we strangely still have builds with artifacts that are older than 90days. As these artifacts are rather big (>1GB) Jenkins is quickly running out of space.
After a bit of browsing through the Jenkins code I found a few lines of code that likely cause this issue:
|
if (r == lsb) { |
|
LOGGER.log(FINER, "{0} is not to be removed or purged of artifacts because it’s the last successful build", r); |
|
return true; |
|
} |
|
if (r == lstb) { |
|
LOGGER.log(FINER, "{0} is not to be removed or purged of artifacts because it’s the last stable build", r); |
|
return true; |
|
} |
A few statements regarding these lines of code:
1. According to git these lines were introduced 13 years ago with https://issues.jenkins.io/browse/JENKINS-2417. Some kind of flag inside Logrotater (like ``boolean alsoDeleteLastStableBuild``) would be helpful, if this behavior is not wanted like described above.
2. The above lines are not documented inside the "Global Build Discarders":
Originally reported by ab_xdev, imported from: Don't keep Build Discarder/Logrotator's last stable/successful builds forever
- status: Closed
- priority: Major
- component(s): core
- resolution: Fixed
- resolved: 2024-08-27T12:45:30+00:00
- votes: 1
- watchers: 2
- imported: 2025-11-24
Raw content of original issue
We current have the following Release workflow:
Every few days or weeks a new release-branch is created. This branch is then built and artifacts get archived. We usually keep the release-Branches over a year, so that we can compare any changes.
We also use the global build discarder with "days to keep artifacts"=90.
However we strangely still have builds with artifacts that are older than 90days. As these artifacts are rather big (>1GB) Jenkins is quickly running out of space.
After a bit of browsing through the Jenkins code I found a few lines of code that likely cause this issue:
|
if (r == lsb) { |
|
LOGGER.log(FINER, "{0} is not to be removed or purged of artifacts because it’s the last successful build", r); |
|
return true; |
|
} |
|
if (r == lstb) { |
|
LOGGER.log(FINER, "{0} is not to be removed or purged of artifacts because it’s the last stable build", r); |
|
return true; |
|
} |
A few statements regarding these lines of code:
1. According to git these lines were introduced 13 years ago with https://issues.jenkins.io/browse/JENKINS-2417. Some kind of flag inside Logrotater (like ``boolean alsoDeleteLastStableBuild``) would be helpful, if this behavior is not wanted like described above.
2. The above lines are not documented inside the "Global Build Discarders":
1 attachment
We current have the following Release workflow:
Every few days or weeks a new release-branch is created. This branch is then built and artifacts get archived. We usually keep the release-Branches over a year, so that we can compare any changes.
We also use the global build discarder with "days to keep artifacts"=90.
However we strangely still have builds with artifacts that are older than 90days. As these artifacts are rather big (>1GB) Jenkins is quickly running out of space.
After a bit of browsing through the Jenkins code I found a few lines of code that likely cause this issue:
jenkins/core/src/main/java/hudson/tasks/LogRotator.java
Lines 233 to 240 in ac66b47
A few statements regarding these lines of code:
1. According to git these lines were introduced 13 years ago with https://issues.jenkins.io/browse/JENKINS-2417. Some kind of flag inside Logrotater (like ``boolean alsoDeleteLastStableBuild``) would be helpful, if this behavior is not wanted like described above.
2. The above lines are not documented inside the "Global Build Discarders":
Originally reported by ab_xdev, imported from: Don't keep Build Discarder/Logrotator's last stable/successful builds forever
Raw content of original issue
1 attachment