Closed nightskyguy closed 2 years ago
damianszczepanik
commented
3 years ago This is not a bug. This is a feature.
Imagine the situation when you are designing rules and conditions for new job. This helps you to prove that configuration is correct. This also helps me to fix the problem in case user reports bug.
nightskyguy
commented
2 years ago This makes your plugin incompatible with our use of Jenkins. We can't afford thousands and thousands of lines of INFO level debugging that swamps all other logs. If someone DID need to debug, they could always add logging via the log manager.
Checking if Cloudbees supports SUPPRESSING logs using the log manager... but this is the first (and only) plugin we've used that exhibits this overabundance of logs.
https://support.cloudbees.com/hc/en-us/articles/204880580/comments/4408473755675
a-wildman
commented
2 years ago I disagree that this is a 'feature' -- such logging should occur at level DEBUG or TRACE. One can always set a custom logging level for a specific package if one wants to inspect how new rules are being evaluated.
On my Jenkins instance, INFO logging for this plugin is 844K lines per minute.
INFO is clearly not the right level for this kind of output.
damianszczepanik
commented
2 years ago The goal is to show those log at job level not Jenkins level because access to the first is generally allowed for everyone while Jenkins logs is available only for admins
a-wildman
commented
2 years ago This is a fair goal, but the problem is that these are not being logged at the job level, they are going to the Jenkins log itself.
On Feb 21, 2022, at 4:09 AM, Damian Szczepanik @.***> wrote:
The goal is to show those log at job level not Jenkins level because access to the first is generally allowed for everyone while Jenkins logs is available only for admins
— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.
damianszczepanik
commented
2 years ago That's true and this is because code that clears old jobs has no access to job context
phillipjohnston
commented
2 years ago This is definitely a problem that the default is DEBUG and not INFO, it is a ton of output. Why is it a feature to use up file system space and clutter a log with undesired information?
damianszczepanik
commented
2 years ago @phillipjohnston @nightskyguy @a-wildman can you review https://github.com/jenkinsci/build-history-manager-plugin/pull/59 - does it solve this problem ?
damianszczepanik
commented
2 years ago Published
Version report
Jenkins and plugins versions report:
Reproduction steps
Results
Expected result:
I expect perhaps one or two log messages per build - independent of the number of builds in the job or the number of rules.
Something like
Processing BuildHistory for Job X build number N with 200 builds. Applying 4 rules. ... Done process BuildHistory for Job X build number N: 23 builds deleted, 2 logs removed, 0 artifacts removed.
I also expect that a DEBUG level log could be set to determine what rule(s) are being applied. But this level of detail should only be enabled if DEBUG level logging is enabled.
Actual result:
Info Level logging swamps the Jenkins log (this example is from kibana in reverse order). Here are 138 messages from ONE build with only 8 retained builds. Note that this came from Kibana and was resorted to restore proper order, so may not match the actual log order (since it will sort two records with the same time alphabetically). However these are all the log messages that were received.