Open WitoDelnat opened 8 months ago
This is related to a feature in SARIF where you have a uri
together with uriBaseId
(e.g. SRCROOT
). Afterwards, the run should contain an object originalUriBaseIds
which map that uriBaseId to the actual URI (e.g. /users/johnsnow/code/). The problem is that our current @monokle/validation does not add this originalUriBaseIds and that makes the SARIF VSC Extension attempt to guess the right file, but given that there are multiple, it fails to do so.
How to fix? We attempted to fix this by taking a SARIF generated by Monokle and manually added the object originalUriBaseIds object with values fitting for our local computer. At that point, it no longer tries to attempt to guess the right file and it properly can allocate problems even if multiple have the same file name.
// Something like this
"originalUriBaseIds": {
"SRCROOT": {
"uri": "file:///"
}
},
The SARIF spec talks more about this topic of the presence and absence of this property. Often it's desired to omit it due to privacy concerns (user name leaks) and non-determinism (different content hashes).
The solution, is for the Monokle Validator to be configurable, and optionally, include this information in the response. We need to determine how to do this properly for each operating system (Windows, Linux, MacOS).
For MacOS it looks like this, in which case file:///
should be the SRC ROOT value. The same applies to Linux. We still need to determine it on Windows.
{"artifactLocation":{"uriBaseId":"SRCROOT","uri":"Users/john/code/monokle-example/basic/nginx.yaml"}
It seems to be same on Windows, some refs:
Might be related also to https://github.com/kubeshop/monokle-core/issues/448.
It was mostly fixed by https://github.com/kubeshop/monokle-core/pull/588 and #75.
However, one issue still remains. Repro steps:
Developer: Restart
command).When file is reopened it works fine. Seems like SARIF is not processing initially opened files. When we debugged initial issue, there is an array storing file references which is propagated when file is opened. And then if there is no match it will try to find a file based on filename - if the filename is not unique across a project this fails. What I suspect is that initially opened files are not added to mentioned file array (unless reopened) and files with no distinct name cannot be matched then and highlighting cannot be applied.
Reproduction