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

Groovy Parsers - improve help text

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: warnings-plugin
    • Labels:
      None
    • Environment:
      Jenkins ver. 2.138.3 (Docker Hub)
      Wanings NG 1.0.0-beta5
    • Similar Issues:
    • Released As:
      warnings-ng 1.0.1

      Description

      The configuration and functionality is currently lacking

      1) The help text under the Static Analysis Tool configuration (Freestyle job), should add that the own configured Parser can be found if "Groovy Parser" is selected

       

      For each static analysis tool a dedicated parser will be used to read the report files. If your tool is not yet supported then you can create your own parser in the system configuration.

       

      2) Groovy Parser cant scan console log output ?!
      Seems a bit weird to me that a single scanner has this limitation, is this getting fixed, or is there a recommendation to start writing logs to a file first? (As in best practices, generally for Jenkins or specific to this plugin). like using "2>&1 | tee some.log" on commands?

       

      FATAL: Static analysis tool Groovy Parser cannot scan console log output, please define a file pattern

       

       

        Attachments

          Activity

          Hide
          drulli Ulli Hafner added a comment -

          Can you please split this issue so that I can track the progress individually?

          The second point is related to JENKINS-52237. Scanning of the console log is done on the master currently, all other files are scanned on the agent. On the master a Groovy script could do harmful things. If I allow a parser script configuration in a job this might be too dangerous. So I thought it would be better to disable processing of Groovy scripts on the master. Do you have a better idea?

          Can’t you pipe your log output to a file on the agent?

          Show
          drulli Ulli Hafner added a comment - Can you please split this issue so that I can track the progress individually? The second point is related to JENKINS-52237 . Scanning of the console log is done on the master currently, all other files are scanned on the agent. On the master a Groovy script could do harmful things. If I allow a parser script configuration in a job this might be too dangerous. So I thought it would be better to disable processing of Groovy scripts on the master. Do you have a better idea? Can’t you pipe your log output to a file on the agent?
          Hide
          nolange79 Norbert Lange added a comment -
          Scanning of the console log is done on the master currently, all other files are scanned on the agent....Do you have a better idea?
          

          I would try to move all processing to the agent(s), its not obvious to me why this split exists (has to exist).

          Can’t you pipe your log output to a file on the agent?
          

          Yes I can, but not without issues. Some variants:

          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

          That's why I asked about a recommendation (a bug tracker is the wrong place, but you don't have a forum?)

          As for the split, keep the help-text issue here, and handle the rest in JENKINS-52237?

          Show
          nolange79 Norbert Lange added a comment - Scanning of the console log is done on the master currently, all other files are scanned on the agent....Do you have a better idea? I would try to move all processing to the agent(s), its not obvious to me why this split exists (has to exist). Can’t you pipe your log output to a file on the agent? Yes I can, but not without issues. Some variants: not piping would be the most clear, and similar to the scripts you would run on a local build piping it just to a file will remove all visible status during execution naively splitting it (eg. | tee file.log) will mean the error state of the script doing the build will vanish. see here additionally storing and restoring the errors state of the script adds boilerplate code That's why I asked about a recommendation (a bug tracker is the wrong place, but you don't have a forum?) As for the split, keep the help-text issue here, and handle the rest in JENKINS-52237 ?
          Hide
          drulli Ulli Hafner added a comment -

          Actually a new issue would be better, these are somewhat opposite requests. Then we see if JENKINS-52237 or scanning the console log with Groovy should be implemented first.

          Show
          drulli Ulli Hafner added a comment - Actually a new issue would be better, these are somewhat opposite requests. Then we see if JENKINS-52237 or scanning the console log with Groovy should be implemented first.

            People

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

              Dates

              Created:
              Updated:
              Resolved: