[JENKINS-73692] Turn off logging from BackgroundGlobalBuildDiscarder

[jglick]

JENKINS-73692: I noticed that a support bundle (support-core) contained task-logs/Periodic background build discarder.log, task-logs/Periodic background build discarder.log.1, etc., each running around 10Mb. #5802 noted that this could happen

BackgroundGlobalBuildDiscarder will currently print something every hour if there are any jobs defined

but it was not obvious how serious this was at the time on a large controller with thousands of jobs. While it only runs every hour, and takes just a minute or so in this big controller, each time it spews out close to 2Mb of text. Worse, the log messages are almost completely uninformative since they only depend on the static configuration, not whether or not builds (or their artifacts) were actually deleted!

Testing done

Created two projects, one with a build discarder set, the other not; and configured a global build discarder.

diff --git core/src/main/java/jenkins/model/BackgroundGlobalBuildDiscarder.java core/src/main/java/jenkins/model/BackgroundGlobalBuildDiscarder.java
index 943a7fd04b..5c0c568984 100644
--- core/src/main/java/jenkins/model/BackgroundGlobalBuildDiscarder.java
+++ core/src/main/java/jenkins/model/BackgroundGlobalBuildDiscarder.java
@@ -75,6 +72,6 @@ public class BackgroundGlobalBuildDiscarder extends AsyncPeriodicWork {
 
     @Override
     public long getRecurrencePeriod() {
-        return HOUR;
+        return 1000;
     }
 }

and then watched the file. Every second it would print

Started at Mon Aug 26 14:54:57 EDT 2024
Processing xxx
Offering xxx to Project Build Discarder
xxx accepted by Project Build Discarder
Offering xxx to Specific Build Discarder
xxx accepted by Specific Build Discarder
Processing yyy
Offering yyy to Project Build Discarder
Offering yyy to Specific Build Discarder
yyy accepted by Specific Build Discarder
Finished at Mon Aug 26 14:54:57 EDT 2024. 1ms

With the patch, the file is no longer touched.

Proposed changelog entries

• No longer printing verbose and uninformative messages to $JENKINS_HOME/logs/tasks/Periodic background build discarder.log.

Proposed upgrade guidelines

N/A

Before the changes are marked as ready-for-merge:

Maintainer checklist

Beta Give feedback

1. There are at least two (2) approvals for the pull request and no outstanding requests for change.
2. Conversations in the pull request are over, or it is explicit that a reviewer is not blocking the change.
3. Changelog entries in the pull request title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood.
4. Proper changelog labels are set so that the changelog can be generated automatically.
5. If the change needs additional upgrade steps from users, the upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the pull request title (see example).
6. If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[MarkEWaite]

@jglick should this be considered for backporting to the 2.462.2 LTS release?

[MarkEWaite]

This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback.

/label ready-for-merge

[jglick]

should this be considered for backporting

It could be. jenkinsci/support-core-plugin#573 (if accepted) would address the most important symptom even on older cores, but just avoiding the disk space is probably reason enough. I will file an issue for it.