• Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Minor Minor
    • analysis-model
    • None
    • 5.0.0 (analysis-model and warnings-ng)

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

          [JENKINS-56700] Use LookaheadParser for GhsMultiParser

          Hello drulli,

          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

          Sebastian Heunke added a comment - Hello drulli , 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

          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).

          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).

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

              Created:
              Updated:
              Resolved: