Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix VSC native problems on files with same name #73

Open
WitoDelnat opened this issue Dec 12, 2023 · 3 comments
Open

Fix VSC native problems on files with same name #73

WitoDelnat opened this issue Dec 12, 2023 · 3 comments
Labels
bug Something isn't working

Comments

@WitoDelnat
Copy link

WitoDelnat commented Dec 12, 2023

Reproduction

  • Create two files called deployment.yaml within different directories. Alternatively you can use the monokle-demo repository.
  • Make them have a misconfiguration (e.g. replicas as a string).
  • Restart VSCode
  • 💥 Problems will be missing from the Problems tab in the bottom component and no longer be highlighted.
  • Workaround: Rename one of the two files and it will appear, restarting VSCode will work properly.
@WitoDelnat WitoDelnat added the bug Something isn't working label Dec 12, 2023
@WitoDelnat
Copy link
Author

WitoDelnat commented Dec 12, 2023

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).

Appendix

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"}

@f1ames
Copy link
Contributor

f1ames commented Dec 12, 2023

It seems to be same on Windows, some refs:

Might be related also to kubeshop/monokle-core#448.

@f1ames
Copy link
Contributor

f1ames commented Dec 14, 2023

It was mostly fixed by kubeshop/monokle-core#588 and #75.

However, one issue still remains. Repro steps:

  1. Open file which has some violations (highlights). The name file shouldn't be distinct across project (there should be at least one additional file with the same name).
  2. Restart VSCode (e.g. via Developer: Restart command).
  3. Upon opening, the file will be opened and no highlighting applied.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants