| Having the Groovy based warnings parser is a great way to support new tools that reports warnings. It might be useful when you write the report (because you write the static analyser or because you plug something into an existing tool). —
Example: For example I have create an extension for Asciidoctor, that collects the issues reported and put them into a file like this.
/tmp/file.adoc|5|ERROR|include file not found: /tmp/other.adoc
/tmp/file.adoc|7|HIGH|list item index: expected 1, got 8
UNKNOWN|0|HIGH|skipping reference to missing attribute: bla
Thank to the Groovy based warnings parser, I can use a regex ((.)|(\d+)|(.)|(.*)) to parse the log that I have created. Read more about this: https://jmini.github.io/asciidoctorj-file-logger/ — The next step for me would be to contribute the parser to this project, so that it no longer rely on a config in Jenkins. But before doing this, I would like to challenge the format that is used...
I could not find any discussion about this. One idea that I have: a collection of JSON structures on each line:
{"fileName": "/tmp/file.adoc", "lineStart": "5", "severity": "ERROR", "message": "include file not found: /tmp/other.adoc"}
{"fileName": "/tmp/file.adoc", "lineStart": "7", "severity": "HIGH", "message": "list item index: expected 1, got 8"}
{"severity": "HIGH", "message": "skipping reference to missing attribute: bla"}
This might be more robust, because the semantic is clearly defined (and not based on a regex config). I think this kind of files are now really common with tools like logstash (using JSON Layout in logger framework). In comparison to xml based file, this kind of format works with tools that works with an append-only approach. Thank in advance for your feedback. —
Related issue:
|
