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

Provide report filename as variable to Groovy parser

    • Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Critical Critical
    • warnings-plugin
    • None
    • jenkins 1.504 + warning plug-in 4.35
    • 5.0.0-beta3

      When using Warning plug-in for parsing several files like *.rpt I would like to be able to display the name of the file being scanned as a category or something else.

      is is possible to catch the filename of the file being scanned in the groovy script of the plugin configuration ?

      for instance :

      test1.rpt contains : "error 1 warning 3"

      test2.rpt contains : "error 10 warning 32"

      test3.rpt contains : "error 132 warning 33"

      And I would like to be able in the parser to catch these lines but including the filename that contains the line. is it something possible ?

      I'm in the case where I don't scan the console but several files.

          [JENKINS-52058] Provide report filename as variable to Groovy parser

          Ulli Hafner added a comment -

          Severity is the new name in all of the libraries. You can clean up your job with missing references to priority.

          Ulli Hafner added a comment - Severity is the new name in all of the libraries. You can clean up your job with missing references to priority.

          Ulli Hafner added a comment -

          Second file name property: this makes not much sense for the other tools. Normally you are not interested in the name of the report, the link shows the affected code.

          Ulli Hafner added a comment - Second file name property: this makes not much sense for the other tools. Normally you are not interested in the name of the report, the link shows the affected code.

          iostrym added a comment -

          thanks: unreadable data delete with success.

          second file name property : suppose you are doing an FPGA synthesis. then there is a warning with path of the source code affected. using your parser I can catch the name of the source file. But it would be great also if I can also link to the complete report at correct line in the report. because often an error is the consequence of one or more warning that written before the error.

          This is why the view of the complete log is usefull. 

          Using your parser and last modification I can do this but then I will loose the affected source code link.

          For testing : no problem your modification is enough because there is no affected code to link with so I can use the report name and line as "file attribute"

          But for synthesis or place&route it could be usefull to have this feature.

          synthesis may be like compilation, it is the same kind of process but for FPGA. I don't remember well how sw compiler generates warning but for synthesis and place&route, very often an error is understood by the presence of warnings before the error.

          iostrym added a comment - thanks: unreadable data delete with success. second file name property : suppose you are doing an FPGA synthesis. then there is a warning with path of the source code affected. using your parser I can catch the name of the source file. But it would be great also if I can also link to the complete report at correct line in the report. because often an error is the consequence of one or more warning that written before the error. This is why the view of the complete log is usefull.  Using your parser and last modification I can do this but then I will loose the affected source code link. For testing : no problem your modification is enough because there is no affected code to link with so I can use the report name and line as "file attribute" But for synthesis or place&route it could be usefull to have this feature. synthesis may be like compilation, it is the same kind of process but for FPGA. I don't remember well how sw compiler generates warning but for synthesis and place&route, very often an error is understood by the presence of warnings before the error.

          Ulli Hafner added a comment -

          Yes, I understand that this feature makes sense in your case. I think this requires changes in the UI as well, so this cannot be implemented in the Groovy parser component. I think such a feature needs to be implemented in Java (e.g. as a new plug-in that depends on the warnings plugin). The DRY parser does something similar. It creates issues that have references to other source code (the duplications).

          Ulli Hafner added a comment - Yes, I understand that this feature makes sense in your case. I think this requires changes in the UI as well, so this cannot be implemented in the Groovy parser component. I think such a feature needs to be implemented in Java (e.g. as a new plug-in that depends on the warnings plugin). The DRY parser does something similar. It creates issues that have references to other source code (the duplications).

          iostrym added a comment -

          thanks for your answer. another suggestion : without modification in the UI (what is it ? jenkins core part ?), is it possible to have the category or type field in the groovy script to behave like a file field ? it means that if I put a filename in this field, then when reading result I could be able to click on filename in category/type field and have a link to open the corresponding file ? and the same for the line number in the file

          iostrym added a comment - thanks for your answer. another suggestion : without modification in the UI (what is it ? jenkins core part ?), is it possible to have the category or type field in the groovy script to behave like a file field ? it means that if I put a filename in this field, then when reading result I could be able to click on filename in category/type field and have a link to open the corresponding file ? and the same for the line number in the file

          Ulli Hafner added a comment -

          No, the file column is hard coded. All other columns navigate into the details of the selected element.

          Ulli Hafner added a comment - No, the file column is hard coded. All other columns navigate into the details of the selected element.

          iostrym added a comment -

          hello, is it normal that using new plugin, I don't find anymore the choice to parse directly the console output instead of a specific report file ?

          iostrym added a comment - hello, is it normal that using new plugin, I don't find anymore the choice to parse directly the console output instead of a specific report file ?

          Ulli Hafner added a comment -

          Please use the Gitter channel for questions.

          You still can parse the Console log, just specify no pattern.

          Ulli Hafner added a comment - Please use the Gitter channel for questions. You still can parse the Console log, just specify no pattern.

          iostrym added a comment -

          Hello,

          Could you please tell me if 5.0 beta version I tried is now available in the official jenkins plugin store ? Is it compatible with the one I installed ?

          sorry, I'm waiting for my company autorize us to use the gitter channel

          best regards,

          iostrym added a comment - Hello, Could you please tell me if 5.0 beta version I tried is now available in the official jenkins plugin store ? Is it compatible with the one I installed ? sorry, I'm waiting for my company autorize us to use the gitter channel best regards,

          Ulli Hafner added a comment -

          The current version is still in beta and available at the official but experimental update center: https://updates.jenkins.io/experimental/

          Ulli Hafner added a comment - The current version is still in beta and available at the official but experimental update center: https://updates.jenkins.io/experimental/

            drulli Ulli Hafner
            iostrym iostrym
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: