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-71596] Provide a git plugin option to hide git logs

          Mark Waite added a 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.

          Mark Waite added a 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.

          Jagruti added a comment - - edited

          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?

          Jagruti added a comment - - edited 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?

          Mark Waite added a 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.

          Mark Waite added a 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.

          Jagruti added a 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?

          Jagruti added a 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?

          Mark Waite added a 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.

          Mark Waite added a 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.

          Jagruti added a comment - - edited

          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.

          Jagruti added a comment - - edited 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.

          Mark Waite added a 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.

          Mark Waite added a 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.

          Jagruti added a comment -

          Jagruti added a comment - I have made a PR here: https://github.com/jenkinsci/git-client-plugin/pull/1066

            acaiblog acai
            acaiblog acai
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: