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

Use LookaheadParser for GhsMultiParser

    Details

    • Similar Issues:
    • Released As:
      5.0.0 (analysis-model and warnings-ng)

      Description

      The parser should not base on the deprecated class anymore. Additionally, the new severity error should be used.

        Attachments

          Activity

          Hide
          hmsebas Sebastian Heunke added a comment -

          Hello Ulli Hafner,

          I have a few questions regarding the requested improvement.

          Is an implementation of this Parser using the RegexpLineParser even possible with its current interface?
          The Pattern Matched by the GhsMultiParser matches multiple lines at once to group the issue message properly.
          It is possible to just match the Start of the issue without the message but that would skip the following lines containing the issue message.

          The RegexpLineParser does not offer a interface to access addtional lines.

          Would it be okay to use the LookaheadParser directly instead? This would allow the GhsMultiParser to read the issue message correctly and proccess the message lines before continuing parsing.

           

          Regarding the severity error request, does this just mean if the error contains the type error the Serverity.ERROR should be used instead of Severity.WARNING_HIGH ?

          Greetings
          Sebastian

          Show
          hmsebas Sebastian Heunke added a comment - Hello Ulli Hafner , I have a few questions regarding the requested improvement. Is an implementation of this Parser using the RegexpLineParser even possible with its current interface? The Pattern Matched by the GhsMultiParser matches multiple lines at once to group the issue message properly. It is possible to just match the Start of the issue without the message but that would skip the following lines containing the issue message. The RegexpLineParser does not offer a interface to access addtional lines. Would it be okay to use the LookaheadParser directly instead? This would allow the GhsMultiParser to read the issue message correctly and proccess the message lines before continuing parsing.   Regarding the severity error request, does this just mean if the error contains the type error the Serverity.ERROR should be used instead of Severity.WARNING_HIGH ? Greetings Sebastian
          Hide
          drulli Ulli Hafner added a comment -

          have a few questions regarding the requested improvement.
          Is an implementation of this Parser using the RegexpLineParser even possible with its current interface?
          The Pattern Matched by the GhsMultiParser matches multiple lines at once to group the issue message properly.
          It is possible to just match the Start of the issue without the message but that would skip the following lines containing the issue message.
          The RegexpLineParser does not offer a interface to access addtional lines.
          Would it be okay to use the LookaheadParser directly instead? This would allow the GhsMultiParser to read the issue message correctly and proccess the message lines before continuing parsing.

          Yes, you are right. I need to change the title of the issue. You need to use the LookaheadParser. Split the regex into two pieces: first part matches the first line. Use this regexp for the LookaheadParser. Then you can decide how many additional lines to read (and if you need the rest of the regexp).

          Regarding the severity error request, does this just mean if the error contains the type error the Serverity.ERROR should be used instead of Severity.WARNING_HIGH ?

          Well, a warning should be mapped to a WARNING_NORMAL. An error to ERROR. You can use the method guessSeverity on the IssueBuilder instance and remove the current mapPriority method.

          Maybe you even find an example in the internet that shows a log of the parser that contains an error (if not, create a fake one).

          Show
          drulli Ulli Hafner added a comment - have a few questions regarding the requested improvement. Is an implementation of this Parser using the RegexpLineParser even possible with its current interface? The Pattern Matched by the GhsMultiParser matches multiple lines at once to group the issue message properly. It is possible to just match the Start of the issue without the message but that would skip the following lines containing the issue message. The RegexpLineParser does not offer a interface to access addtional lines. Would it be okay to use the LookaheadParser directly instead? This would allow the GhsMultiParser to read the issue message correctly and proccess the message lines before continuing parsing. Yes, you are right. I need to change the title of the issue. You need to use the LookaheadParser . Split the regex into two pieces: first part matches the first line. Use this regexp for the LookaheadParser . Then you can decide how many additional lines to read (and if you need the rest of the regexp). Regarding the severity error request, does this just mean if the error contains the type error the Serverity.ERROR should be used instead of Severity.WARNING_HIGH ? Well, a warning should be mapped to a WARNING_NORMAL . An error to ERROR . You can use the method guessSeverity on the IssueBuilder instance and remove the current mapPriority method. Maybe you even find an example in the internet that shows a log of the parser that contains an error (if not, create a fake one).

            People

            • Assignee:
              hmsebas Sebastian Heunke
              Reporter:
              drulli Ulli Hafner
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: