[JENKINS-71596] Provide a git plugin option to hide git logs

[jenkins-infra-bot]

I want to hidden git log,eg:

Started by user acai Loading library ops-lib@​master Attempting to resolve master from remote references... > git --version # timeout=10 > git --version # 'git version 2.30.2' using GIT_ASKPASS to set credentials gitee密码 > git ls-remote -h – https://gitee.com/acaiblog/libraries.git # timeout=10 Found match: refs/heads/master revision 7d28fd8619888375db12f965be491319b6afa9c2 > git rev-parse --resolve-git-dir /var/jenkins_home/workspace/aaa@​libs/9fa4d5b31656b386121512d2efe921ecd112ae9bc24b6af3b921704457ba5822/.git # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url https://gitee.com/acaiblog/libraries.git # timeout=10 Fetching without tags Fetching upstream changes from https://gitee.com/acaiblog/libraries.git > git --version # timeout=10 > git --version # 'git version 2.30.2' using GIT_ASKPASS to set credentials gitee密码 > git fetch --no-tags --force --progress – https://gitee.com/acaiblog/libraries.git +refs/heads/:refs/remotes/origin/ # timeout=10 Checking out Revision 7d28fd8619888375db12f965be491319b6afa9c2 (master) > git config core.sparsecheckout # timeout=10 > git checkout -f 7d28fd8619888375db12f965be491319b6afa9c2 # timeout=10 Commit message: "新增日志时间戳" [Pipeline] Start of Pipeline [Pipeline] echo [2023-07-06 10:59:56] INFO: info [Pipeline] echo [2023-07-06 10:59:56] DEBUG: debug [Pipeline] End of Pipeline Finished: SUCCESS

 

JenkinsFile:

@​Library('ops-lib@​master') _
log.info "info"
log.debug "debug"

 

---

Originally reported by acaiblog, imported from: Provide a git plugin option to hide git logs

• assignee: acaiblog
• status: Open
• priority: Minor
• component(s): git-client-plugin
• label(s): git
• resolution: Unresolved
• votes: 0
• watchers: 3
• imported: 20251211-071809

Raw content of original issue

I want to hidden git log,eg:

Started by user acai Loading library ops-lib@master Attempting to resolve master from remote references... > git --version # timeout=10 > git --version # 'git version 2.30.2' using GIT_ASKPASS to set credentials gitee密码 > git ls-remote -h – https://gitee.com/acaiblog/libraries.git # timeout=10 Found match: refs/heads/master revision 7d28fd8619888375db12f965be491319b6afa9c2 > git rev-parse --resolve-git-dir /var/jenkins_home/workspace/aaa@libs/9fa4d5b31656b386121512d2efe921ecd112ae9bc24b6af3b921704457ba5822/.git # timeout=10 Fetching changes from the remote Git repository > git config remote.origin.url https://gitee.com/acaiblog/libraries.git # timeout=10 Fetching without tags Fetching upstream changes from https://gitee.com/acaiblog/libraries.git > git --version # timeout=10 > git --version # 'git version 2.30.2' using GIT_ASKPASS to set credentials gitee密码 > git fetch --no-tags --force --progress – https://gitee.com/acaiblog/libraries.git +refs/heads/:refs/remotes/origin/ # timeout=10 Checking out Revision 7d28fd8619888375db12f965be491319b6afa9c2 (master) > git config core.sparsecheckout # timeout=10 > git checkout -f 7d28fd8619888375db12f965be491319b6afa9c2 # timeout=10 Commit message: "新增日志时间戳" [Pipeline] Start of Pipeline [Pipeline] echo [2023-07-06 10:59:56] INFO: info [Pipeline] echo [2023-07-06 10:59:56] DEBUG: debug [Pipeline] End of Pipeline Finished: SUCCESS

 

JenkinsFile:

@Library('ops-lib@master') _
log.info "info"
log.debug "debug"

 

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  Git logs are intentionally displayed due to the number of times that diagnosis has been required.  If you'd like to reduce the verbosity of the logs, it would need enhancements to the git client plugin to provide either a global setting that reduces verbosity or a setting per job that reduces verbosity.  Refer to the git client plugin contributing guide and the git plugin contributing guide for more details.
  

Git logs are intentionally displayed due to the number of times that diagnosis has been required. If you'd like to reduce the verbosity of the logs, it would need enhancements to the git client plugin to provide either a global setting that reduces verbosity or a setting per job that reduces verbosity. Refer to the git client plugin contributing guide and the git plugin contributing guide for more details.

[jenkins-infra-bot]

jagrutiti:

• Original comment link
• Raw content of original comment:

  Hi markewaite,
  
  I gave a read to: https://plugins.jenkins.io/scm-api/.  I also went through the repo: https://github.com/jenkinsci/scm-api-plugin/
  
  But did not really find things about logs verbosity. 
  
  Could you tell me what I should look for?
  

Hi markewaite,

I gave a read to: https://plugins.jenkins.io/scm-api/. I also went through the repo: https://github.com/jenkinsci/scm-api-plugin/

But did not really find things about logs verbosity.

Could you tell me what I should look for?

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  Thanks for your interest jagrutiti.  You've chosen a challenging improvement.  The logged statements are usually written by listener.getLogger().println().  This enhancement suggests that a global configuration to suppress logs might be added or that a per job configuration might be allowed.  The calls to listener.getLogger().println() will need to be reworked to be conditional based on a setting.
  

Thanks for your interest jagrutiti. You've chosen a challenging improvement. The logged statements are usually written by listener.getLogger().println(). This enhancement suggests that a global configuration to suppress logs might be added or that a per job configuration might be allowed. The calls to listener.getLogger().println() will need to be reworked to be conditional based on a setting.

[jenkins-infra-bot]

jagrutiti:

• Original comment link
• Raw content of original comment:

  Hi markewaite,
  
  I went through the code, and found that `listener` is an object of the  `TaskListener` class: https://javadoc.jenkins-ci.org/hudson/model/TaskListener.html. 
  
  The class is written here: https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/TaskListener.java
  
  Do I have to make the changes in this repo? 
  

Hi markewaite,

I went through the code, and found that `listener` is an object of the `TaskListener` class: https://javadoc.jenkins-ci.org/hudson/model/TaskListener.html.

The class is written here: https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/TaskListener.java

Do I have to make the changes in this repo?

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  Do I have to make the changes in this repo?
  
  No, that would change the TaskListener behavior for all jobs and for all cases. I doubt the maintainers of Jenkins core would accept a behavior change for all users.
  
  I think that the git client plugin and the git plugin would need a flag added that allows the administrator or the job user to reduce the log verbosity.  The logging statements in the plugin would need to be adapted to honor that flag.
  

Do I have to make the changes in this repo?

No, that would change the TaskListener behavior for all jobs and for all cases. I doubt the maintainers of Jenkins core would accept a behavior change for all users.

I think that the git client plugin and the git plugin would need a flag added that allows the administrator or the job user to reduce the log verbosity. The logging statements in the plugin would need to be adapted to honor that flag.

[jenkins-infra-bot]

jagrutiti:

• Original comment link
• Raw content of original comment:

  Here are my ideas for the implementation are:
  
  	
  Create a boolean constant.
  	
  Print all the logs if the value of the constant is false. Otherwise print only the important part of the logs.
  
  
  
  Details of the idea:
  
  	
  How do I identify the important logs or their length? By counting the length of the string?
  	
  As the logs are used in almost all the files. The flag should be global and the constant shouldn't be redundant in each file.
  	
  To implement this should I create another logger class? This class would take care of all the above implementation and would be replaced by the logger statements?
  
  
  
   
  
  I am asking a lot of questions here. I hope I make sense to you. Let me know if I am the wrong path or something.
  

Here are my ideas for the implementation are:

• Create a boolean constant.
• Print all the logs if the value of the constant is false. Otherwise print only the important part of the logs.

Details of the idea:

• How do I identify the important logs or their length? By counting the length of the string?
• As the logs are used in almost all the files. The flag should be global and the constant shouldn't be redundant in each file.
• To implement this should I create another logger class? This class would take care of all the above implementation and would be replaced by the logger statements?

 

I am asking a lot of questions here. I hope I make sense to you. Let me know if I am the wrong path or something.

[jenkins-infra-bot]

markewaite:

• Original comment link
• Raw content of original comment:

  
  Here are my ideas for the implementation are:
  
  	
  Create a boolean constant.
  	
  Print all the logs if the value of the constant is false. Otherwise print only the important part of the logs.
  
  
  
  At the highest level, yes, if detailed logging is enabled, then detailed logging statements are written to the build log of the job.  If detailed logging is disabled, then detailed logging statements are not written to the build log of the job.
  
  
  Details of the idea:
  
  	
  How do I identify the important logs or their length? By counting the length of the string?
  
  
  
  As far as I can tell, length is not relevant to decide whether a message should appear in the build log of the job or not.  The content of the message is the most likely to decide the importance of that message.
  
  Since message content is the best guidance on the importance of the message, the final decision on which statements should be logged is left to the git plugin maintainers that are familiar with the logged statements and their value.
  
  
  
  	
  As the logs are used in almost all the files. The flag should be global and the constant shouldn't be redundant in each file.
  
  
  
  I think that we may want to have each logged message assigned a level, similar to the way that the Java logging facility operates.  Administrators could then choose the default log level that should be displayed.
  
  
  
  	
  To implement this should I create another logger class? This class would take care of all the above implementation and would be replaced by the logger statements?
  
  
  
  I think that is a good idea.  The class might be similar to the Java Logger class but writing to TaskListener rather than to a logging destination.
  

Here are my ideas for the implementation are:

• Create a boolean constant.
• Print all the logs if the value of the constant is false. Otherwise print only the important part of the logs.

At the highest level, yes, if detailed logging is enabled, then detailed logging statements are written to the build log of the job. If detailed logging is disabled, then detailed logging statements are not written to the build log of the job.

Details of the idea:

• How do I identify the important logs or their length? By counting the length of the string?

As far as I can tell, length is not relevant to decide whether a message should appear in the build log of the job or not. The content of the message is the most likely to decide the importance of that message.

Since message content is the best guidance on the importance of the message, the final decision on which statements should be logged is left to the git plugin maintainers that are familiar with the logged statements and their value.

• As the logs are used in almost all the files. The flag should be global and the constant shouldn't be redundant in each file.

I think that we may want to have each logged message assigned a level, similar to the way that the Java logging facility operates. Administrators could then choose the default log level that should be displayed.

• To implement this should I create another logger class? This class would take care of all the above implementation and would be replaced by the logger statements?

I think that is a good idea. The class might be similar to the Java Logger class but writing to TaskListener rather than to a logging destination.

[jenkins-infra-bot]

jagrutiti:

• Original comment link
• Raw content of original comment:

  I have made a PR here: Added new logger class and a test case #1066
  

I have made a PR here: #1066