Details
-
Improvement
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Fixed
-
-
5.2.0
Description
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:
Attachments
Issue Links
- is related to
-
-
- Resolved
-
Activity
Jeremie Bresson
added a comment - Thank you for your feedback.
Is Asciidoctor already a Jenkins Plugin? Note that in this case you can also can consider to directly create the issues using the API rather then working with files at all. Then you do not need to think about flushing of the console log...
I have no idea if there is an Asciidoctor plugin.
Like many java developers and I prefer to orchestrate my build with a tool like maven or gradle.
This way I can run it locally and have the CI server (Jenkins) to reproduce it at server side.
So for me having the build tool flushing logs to a file and having Jenkins to read this file is a valid approach.
Jeremie Bresson
added a comment - Thank you for your feedback.
Is Asciidoctor already a Jenkins Plugin? Note that in this case you can also can consider to directly create the issues using the API rather then working with files at all. Then you do not need to think about flushing of the console log...
I have no idea if there is an Asciidoctor plugin.
Like many java developers and I prefer to orchestrate my build with a tool like maven or gradle.
This way I can run it locally and have the CI server (Jenkins) to reproduce it at server side.
So for me having the build tool flushing logs to a file and having Jenkins to read this file is a valid approach. Jeremie Bresson
added a comment - For the moment Asciidoctor is logging to the console and provide an API to implement a custom Log-Handler.
I think that for the time being, having a small extension that logs to the JSON format is an appropriate way to do it.
Jeremie Bresson
added a comment - For the moment Asciidoctor is logging to the console and provide an API to implement a custom Log-Handler.
I think that for the time being, having a small extension that logs to the JSON format is an appropriate way to do it. Jeremie Bresson
added a comment - I have created a PR: https://github.com/jenkinsci/analysis-model/pull/168
Jeremie Bresson
added a comment - I have created a PR: https://github.com/jenkinsci/analysis-model/pull/168 This is released in edu.hm.hafner:analysis-model:5.1.0
In the Jenkins plugin:
- This is fixed with commit https://github.com/jenkinsci/warnings-ng-plugin/commit/7063463459661cddf65e8e0c1c9b6e6ef6fec05a on the master branch, but not released yet.
- io.jenkins.plugins:warnings-ng:5.1.0 is using edu.hm.hafner:analysis-model:5.0.0 as dependency.
Jeremie Bresson
added a comment - - edited This is released in edu.hm.hafner:analysis-model:5.1.0
In the Jenkins plugin:
This is fixed with commit https://github.com/jenkinsci/warnings-ng-plugin/commit/7063463459661cddf65e8e0c1c9b6e6ef6fec05a on the master branch, but not released yet.
io.jenkins.plugins:warnings-ng:5.1.0 is using edu.hm.hafner:analysis-model:5.0.0 as dependency.
Providing an additional format as JSON is a good idea. I think it is not hard to implement something that reads the existing Issue properties. It basically should do the same thing that an XML parser in
JENKINS-56510is doing. Then users have the choice to use the format that is better matching.Is Asciidoctor already a Jenkins Plugin? Note that in this case you can also can consider to directly create the issues using the API rather then working with files at all. Then you do not need to think about flushing of the console log...