-
Bug
-
Resolution: Fixed
-
Major
-
plugin version 11.3.0 and jenkins 2.452.3
Sarif files are defining 2 tag uriBaseId and originalUriBaseIds to precise file path to access it.
File path = originalUriBaseIds[uriBaseId].uri + / + location.uri
uriBaseId is provided for each file location.
The recordIssues today consider the location.uri of a file from beeing relative to the root of the sarif file itself.
So that if the sarif file is not in the top folder of the source file... file are not found.
Base uri are defined that way:
"originalUriBaseIds": { "SRCROOT0": { "uri": "file:///C:/Jenkins/workspace/_Module_PCS18Z_SmartReceivers_io/CODE/SOURCE/" } },
Used and referenced by such tag:
{
"location": {
"uri": "Application/Classes/ControlPanel/ControlPanel/ControlPanelListener/ControlPanelListener.c",
"uriBaseId": "SRCROOT0"
},
"mimeType": "text/x-c",
"hashes": {
"LOOKUP3-FILENAME+CONTENT": "6cf7a47a86aadbe3"
}
}
Today the plug is loading Application/Classes/ControlPanel/ControlPanel/ControlPanelListener/ControlPanelListener.c and does not find the file as it is not a path from the folder containing the sarif file. (sarif file is put in the build folder in our company).
[JENKINS-73449] No support of originalUriBaseIds and uriBaseId from sarif files
Done : https://github.com/tomasbjerre/violations-lib/issues/189
Hoppe this is clear enough, as I don't know what the violation-libs does provide as interfaces. feal free to put precision in the ticket in case you judge it is not clear enough.
Cyrille Guillard
added a comment - - edited Done : https://github.com/tomasbjerre/violations-lib/issues/189
Hoppe this is clear enough, as I don't know what the violation-libs does provide as interfaces. feal free to put precision in the ticket in case you judge it is not clear enough. I did a few test recently, and something is unclear to me about where/how the files get stored.
I mean the sarif file was generated on a slave (linux or windows) but the jenkins server is another machine, I assume the file are copied onto the controler ?
In any case the link is properly generated if the attribute originalUriBaseIds is limited to 'file:///', as soon as it contains something else the file link is not present and logs complains about missing files for fingerprint.
I got a case where it has a path and the location was limited to the subpath and the plugin was working because called from the correct folder (ie the folder contained in originalUriBaseIds. But this is working by chance in my opinion.
I think originalUriBaseIds is ignored by the plugin (or violation-lib).
Cyrille Guillard
added a comment - - edited I did a few test recently, and something is unclear to me about where/how the files get stored.
I mean the sarif file was generated on a slave (linux or windows) but the jenkins server is another machine, I assume the file are copied onto the controler ?
In any case the link is properly generated if the attribute originalUriBaseIds is limited to 'file:///', as soon as it contains something else the file link is not present and logs complains about missing files for fingerprint.
I got a case where it has a path and the location was limited to the subpath and the plugin was working because called from the correct folder (ie the folder contained in originalUriBaseIds. But this is working by chance in my opinion.
I think originalUriBaseIds is ignored by the plugin (or violation-lib). Cyrille Guillard
added a comment - drulli violations-lib closed the ticket 189 and deliver release 1.157.2 with a fix.
If you can deliver a new version or even a temporary jpi, I can give it a try.
Cyrille Guillard
added a comment - drulli violations-lib closed the ticket 189 and deliver release 1.157.2 with a fix.
If you can deliver a new version or even a temporary jpi, I can give it a try. 
I'm delegating the work to the SARIF parser of the violations-lib.
It looks like SarifParser needs to be improved. I think I can create a test case for the analysis-model, but the actual work must be done in the violations-lib.