• Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • p4-plugin
    • None

      Desire a way to control (limit) the logging in the Console Output.

      For example, when things go wrong in the actual build step, I always have to scroll done through all the P4 Tasks. There's part of the P4 Task output, like p4 info, p4 counter change, p4 client -i, p4 client -o, etc. that I only care about if it fails.

          [JENKINS-40292] More Control of p4 task logging

          Bruce Evans added a comment -

          +vote

          also, this adds volume to the console log even though "quiet" is true in p4sync. Request is to reduce/eliminate but allow setting to re-engage if diagnostics required.

          Bruce Evans added a comment - +vote also, this adds volume to the console log even though "quiet" is true in p4sync. Request is to reduce/eliminate but allow setting to re-engage if diagnostics required.

          William Brode added a comment -

          p4paul I care about this quite a bit and am willing to try to fix it.  I wonder if you would be willing to talk with me about what you are/are not okay with in terms of the default logging and how people can control it?

          William Brode added a comment - p4paul I care about this quite a bit and am willing to try to fix it.  I wonder if you would be willing to talk with me about what you are/are not okay with in terms of the default logging and how people can control it?

          Bruce Evans added a comment -

          Paul - thank you for responding and considering this! 

          I'm finding in my environment, that we report lots of stuff when something fails, but when it works we just move on. I typically write the output of a command to a logfile, and if the operation fails, I echo the logfile to the console, otherwise, I just delete the logfile.  It doesn't need to be a logfile, perhaps just storing the lines in an array, but you get the picture.

          Specifically about this "p4 sync" or "p4 unshelve", etc... I look at "node" step in console (or most other Jenkins API steps), and I see one line when node starts, and one line when the closure ends. Same for "stage", and quite a few others. For normal ops, I think that would be sufficient.

          Because there are many actual P4 commands being executed for each Jenkins API step, that is where the logging/fail/success comes in.

          I hope I'm answering your question. I see this as default logging is absolute minimum, but if something goes wrong, it shows on the console. The user has to do nothing.

          Bruce Evans added a comment - Paul - thank you for responding and considering this!  I'm finding in my environment, that we report lots of stuff when something fails, but when it works we just move on. I typically write the output of a command to a logfile, and if the operation fails, I echo the logfile to the console, otherwise, I just delete the logfile.  It doesn't need to be a logfile, perhaps just storing the lines in an array, but you get the picture. Specifically about this "p4 sync" or "p4 unshelve", etc... I look at "node" step in console (or most other Jenkins API steps), and I see one line when node starts, and one line when the closure ends. Same for "stage", and quite a few others. For normal ops, I think that would be sufficient. Because there are many actual P4 commands being executed for each Jenkins API step, that is where the logging/fail/success comes in. I hope I'm answering your question. I see this as default logging is absolute minimum, but if something goes wrong, it shows on the console. The user has to do nothing.

          Bruce Evans added a comment -

          Apologies!!   William – I misunderstood. you were asking Paul to discuss with you.

          Bruce Evans added a comment - Apologies!!   William – I misunderstood. you were asking Paul to discuss with you.

          William Brode added a comment -

          bevans That's okay, I welcome your feedback as we want to make a change that works for everyone.

          William Brode added a comment - bevans That's okay, I welcome your feedback as we want to make a change that works for everyone.

          Paul Allen added a comment -

          Hi Guys, there are at least two main types of logging in Jenkins the TaskListener the main discussion here and the System Log (java.util.logging).  Over the years I have made improvements to both, but with change in the GUI (Blue Ocean) some of the collapsable html blocks in TaskListener are somewhat redundant.

          Logging with TaskListener occurs in many places; the most common are ConnectionHelper, ClientHelper, Tasks (AbstractTask) and the Perforce commands in P4Logging.

          A Global option to enable/disable logging details may be the simplest; is there a need to set this per job or per connection?  I can see that per job might be preferable.

          The next question would be to determine how many levels and what would be visible for each:

          • sub steps (e.g. updating client, removing file, reconcile files, syncing file)
          • the actual p4 commands
          • detailed output for commands (files being reconciled, full client workspace view mappings)
          • execution time (for a sub step, or even a command)

          Lots to think about?

          Paul Allen added a comment - Hi Guys, there are at least two main types of logging in Jenkins the TaskListener the main discussion here and the System Log (java.util.logging).  Over the years I have made improvements to both, but with change in the GUI (Blue Ocean) some of the collapsable html blocks in TaskListener are somewhat redundant. Logging with TaskListener occurs in many places; the most common are ConnectionHelper, ClientHelper, Tasks (AbstractTask) and the Perforce commands in P4Logging. A Global option to enable/disable logging details may be the simplest; is there a need to set this per job or per connection?  I can see that per job might be preferable. The next question would be to determine how many levels and what would be visible for each: sub steps (e.g. updating client, removing file, reconcile files, syncing file) the actual p4 commands detailed output for commands (files being reconciled, full client workspace view mappings) execution time (for a sub step, or even a command) Lots to think about?

          William Brode added a comment - - edited

          Although every potential option is nice - I think a global setting is likely good enough for now?  And yeah I would just be talking about changes to the TaskListener logging for now.

          Here are the levels I would like to see:

          • ALL
            • what p4 commands are run
            • sub steps
            • all output from p4
          • FINE
            • High level summaries (Creating Client, Syncing workspace, Cleaning workspace)
            • p4 output up to a certain limit (like 5000 lines)
          • INFO
            • High level summary only
          • WARNING
            • Only warnings
          • ERROR
            • Only errors

           

          Of course every level would include warnings and errors.  I know it might be difficult but making a strong effort to include all relevant info when a warning or error occurs could go a long way too.  So once we determine there is an error then we include extra logging on what the p4 command was and the output of that command.

           

          I take it Bruce would be fine with ERROR, while I would likely stick with INFO or FINE.  What do you think of this approach?

          William Brode added a comment - - edited Although every potential option is nice - I think a global setting is likely good enough for now?  And yeah I would just be talking about changes to the TaskListener logging for now. Here are the levels I would like to see: ALL what p4 commands are run sub steps all output from p4 FINE High level summaries (Creating Client, Syncing workspace, Cleaning workspace) p4 output up to a certain limit (like 5000 lines) INFO High level summary only WARNING Only warnings ERROR Only errors   Of course every level would include warnings and errors.  I know it might be difficult but making a strong effort to include all relevant info when a warning or error occurs could go a long way too.  So once we determine there is an error then we include extra logging on what the p4 command was and the output of that command.   I take it Bruce would be fine with ERROR, while I would likely stick with INFO or FINE.  What do you think of this approach?

          Paul Allen added a comment -

          The TaskListener does not have levels, I could extended it to use java.util.logging.Level (all levels are cumulative and include the level above):

          Would the following break down work?

          • SEVERE 
            • Fatal errors that will cause the build to Abort 
          • WARNING
            • Warnings
          • INFO (default level)
            • Intermediate steps (like file cleanup, populate) and just the p4 command
          • CONFIG (not used)
          • FINE
            • p4 command details and output
          • FINER (not used)
          • FINEST (not used)

          Configuring this can be done Globally, per Job, or possibly per Credential.  I'm thinking for large Jenkins deployments if one user is investigating a job he might upset other teams if the setting is global. 

           

          Paul Allen added a comment - The TaskListener does not have levels, I could extended it to use java.util.logging.Level (all levels are cumulative and include the level above): Would the following break down work? SEVERE  Fatal errors that will cause the build to Abort  WARNING Warnings INFO (default level) Intermediate steps (like file cleanup, populate) and just the p4 command CONFIG (not used) FINE p4 command details and output FINER (not used) FINEST (not used) Configuring this can be done Globally, per Job, or possibly per Credential.  I'm thinking for large Jenkins deployments if one user is investigating a job he might upset other teams if the setting is global.   

          Bruce Evans added a comment -

          this works nicely for me

           

          Bruce Evans added a comment - this works nicely for me  

          William Brode added a comment -

          p4paul yes I think that sounds great.

          William Brode added a comment - p4paul yes I think that sounds great.

            p4paul Paul Allen
            joel_brown Joel Brown
            Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: