Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-54832

Groovy Parser cannot access console log

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Component/s: warnings-plugin
    • Labels:
      None
    • Environment:
      Jenkins ver. 2.138.3 (Docker Hub)
      Wanings NG 1.0.0-beta5
    • Similar Issues:

      Description

      (discussion is split from JENKINS-54759)

      Issue

      console parsers currently run on the master and for security reasons, this excludes the customizable Groovy Parser.
      for an user this is surprising and adding a custom warning parser will need changes in the buildscript to dump output to a log file, ideally adding a parser would not otherwise affect existing jobs .

      1. not piping would be the most clear, and similar to the scripts you would run on a local build
      2. piping it just to a file will remove all visible status during execution
      3. naively splitting it (eg. | tee file.log) will mean the error state of the script doing the build will vanish. see here
      4. additionally storing and restoring the errors state of the script adds boilerplate code

      just to reiterate how invasive this change is, here is my current (POSIX Shell) workaround with variant 4):

      before:

      sh buildscript.sh ARGS...
      

      after:

      pipe_retval() {
        local LOGFILE=$1; shift
        (((("$@" 2>&1; echo $? >&3) | tee "$LOGFILE" >&4) 3>&1) | (read xs; exit $xs)) 4>&1
      }
      
      pipe_retval build.log sh buildscript.sh ARGS...
      

        Attachments

          Issue Links

            Activity

            Hide
            saierd Daniel Saier added a comment -

            I have the same problem and currently have to use ugly workarounds.

            As I understand it, this limitation was introduced for JENKINS-52237.  I don't require that functionality and the administrator is the only one who creates Groovy parsers on my system. Would it be possible to lift this restriction again for parsers that are configured through the admin interface (and thus don't have security problems when they run on the master)?

            Show
            saierd Daniel Saier added a comment - I have the same problem and currently have to use ugly workarounds. As I understand it, this limitation was introduced for JENKINS-52237 .  I don't require that functionality and the administrator is the only one who creates Groovy parsers on my system. Would it be possible to lift this restriction again for parsers that are configured through the admin interface (and thus don't have security problems when they run on the master)?
            Show
            drulli Ulli Hafner added a comment - Maybe this thread helps as well: https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/jenkinsci-users/Tkh8v07v_Cs/uvx3az-4BQAJ
            Hide
            nolange79 Norbert Lange added a comment -

            I picked the above workaround, as this works with any POSIX shells, credit goes out to: unix.stackexchange.com.

            the workaround with `set -o pipefail`only works with bash, and therefore does not work if you for ex. use alpine linux.

            Show
            nolange79 Norbert Lange added a comment - I picked the above workaround, as this works with any POSIX shells, credit goes out to: unix.stackexchange.com . the workaround with `set -o pipefail`only works with bash, and therefore does not work if you for ex. use alpine linux.
            Hide
            saierd Daniel Saier added a comment -

            If you don't know it yet, you should take a look at the tee step. This does what it should and automatically propagates the return codes of any failed steps inside of the tee.

            Show
            saierd Daniel Saier added a comment - If you don't know it yet, you should take a look at the tee step . This does what it should and automatically propagates the return codes of any failed steps inside of the tee.
            Hide
            nolange79 Norbert Lange added a comment -

            Daniel Saier: No I did not knew about this yet, I proposed practically the same thing in JENKINS-44930. Thanks.

            That seems to be the proper solution for me now, as I prefer feeding just the output from the build command to the warnings-plugin (vs. using the whole log output)

            Show
            nolange79 Norbert Lange added a comment - Daniel Saier : No I did not knew about this yet, I proposed practically the same thing in JENKINS-44930 . Thanks. That seems to be the proper solution for me now, as I prefer feeding just the output from the build command to the warnings-plugin (vs. using the whole log output)

              People

              Assignee:
              drulli Ulli Hafner
              Reporter:
              nolange79 Norbert Lange
              Votes:
              3 Vote for this issue
              Watchers:
              7 Start watching this issue

                Dates

                Created:
                Updated: