Open mhenke opened 12 years ago
Not clear on the issue here - I haven't used Jenkins, so it all makes less sense than it might otherwise.
Is it basically asking for a more integrated way to pass results from qpscanner to Jenkins, to allow the details of any unparamed variables to be explored through a Jenkins dashboard/ui?
Yes. Most inspection tools create an xml file Jenkins reads and uses for graphs & other integration.
here is a snippet from the jslint inspection xml file created:
< jslint> < file name="\xxx\servers\xxx\cfusion.ear\cfusion.war\tests\inspection\Buttons.js"> < issue line="1" char="9" reason="Expected 'var' at column 1, not column 9." evidence=" var NN3 = false;"/> < issue line="2" char="1" reason="Unexpected '(space)'." evidence=" "/> < issue line="3" char="9" reason="Expected 'rqaddr' at column 1, not column 9." evidence=" rqaddr=new Image();"/> < /file> ....
here are some inspections I created for cfml projects https://github.com/mhenke/Cloudy-With-A-Chance-Of-Tests
here are screenshots of the results in jenkins http://henke.ws/post.cfm/cloudy-with-a-chance-of-tests-screenshots
it is an easy 7 steps as described above, lol :-)
Yep, starting to make sense now.
What's the difference between a "warning" and a "violation" - the jslint thing seems to be the latter, but I don't see why there's two different things?
They are different plugins for jenkins. qpscanner might fit better as a violation but I don't see an easy way to add a new voilation type. Guess if we want it done correctly, it might go into violations.
https://wiki.jenkins-ci.org/display/JENKINS/Violations https://wiki.jenkins-ci.org/display/JENKINS/Warnings+Plugin
https://wiki.jenkins-ci.org/display/JENKINS/Warnings+Plugin
Defining a new parser using the user interface
Since release 3.8 you can define new parsers dynamically in the system configuration section of Jenkins. Just navigate to http://[jenkins-url]/configure and create a new parser in section Compiler Warnings. The UI should be self explanatory, if there is something missing, please let me know on the mailing lists. Writing a new parser that should be included in the warnings plug-in
Extending the existing set of supported warning formats is quite easy. If the format of the warnings messages could be parsed by an regular expression, then you only need to provide a new parser class and a corresponding test case: