As mentionned on the documentation ( Requirements - SonarQube for IDE Documentation - VS Code), to use Sonarlint in vscode with Zowe Explorer we need to set the temporary folder of Zowe Explorer to the workspace folder, because sonarlint is able to scan only workspace files when in connected mode.
Unfortunattely since Zowe Explorer v3, there is no more temporary folder. The cobol source code viewed with Zowe Explorer is directly open in the editor and store in the memory.
Do you have any solution to continue using Sonarlint Vscode for Cobol on source viewed from Zowe Explorer ?
Hello, we made some progress on investigating this issue.
We have several options to fix this properly in the extension, but they will definitely require a bit of work: the ZOWE Explorer is now exposing the mainframe datasets as a virtual file system with a custom URI scheme, and this challenges a few assumptions that we made with the previous version.
A possible workaround would be to manually download the files from the mainframe to a local workspace folder, bind this folder to your SonarQube server, and ultimately upload back the contents to the mainframe with ZOWE when you are done.
Would you be willing to share some details about how the analysis is done on the server side? I can open a private conversation if you prefer to keep the details private.
The process to analyse the cobol code with sonarqube is being under construction. Some have migrate their code to a github repo so they can do the analysis on Sonarqube easily. For user still working with their sources on the mainframe, one analysis has been done with a download of the sources, but this download is not done on a regular basis. It offers our users to have one sonarqube project and be able to connect to it from their vscode IDE for scanning sources which are on the mainframe
I don’t know if that answer your question or not. Please feel free to to ask if you need more informations.
If I understand correctly, this means that most developers don’t have a copy of the COBOL sources on their local file system, and they work directly on datasets on the mainframe through ZOWE. Is this correct?
In this context, how are copybooks resolved? Is there maybe a dedicated dataset or list of datasets that contain copybooks?
There are several parameters that govern how copybooks are handled in the server analysis, but they rely on actual files and directories, so using them in the IDE could prove challenging if the matching folders are not present in developer environments.
It is correct yes, most of them still work directly with their source on the mainframe, editing them though zowe.
Copybook are resolved thank to IBM Z/Open editor extension which provide COBOL langage server and enable to search copybook thank to zowe in a dataset.
hi @RichardSGFR
If you leverage the major server of your group, you should have access to our Premium Support engineers to help you on that specific topic.
Could you reach out to me on my email : carine.bayon@sonarsource.com so we can deep dive a bit further on your existing license (and support contract), and check together the correct path for you to be supported?
I’m just pitching in to say that we also have users at our company that solely use the Zowe Explorer to communcate with the mainframe and has used SonarLint extensively when the files were saved as temp files locally. Now that Zowe uses the VSCode filesystem provider, they don’t have access to Sonarlint/Sonarqube for IDE anymore without having to do alot of manual work (download file, see Sonarlint, make changes, upload file etc.)
Thanks for the valuable feedback. We’ve added this issue to our roadmap and will investigate a suitable fix. The root of the problem is that Zowe Explorer V3 now operates on remote files without creating a temporary local copy, which prevents our analyzers from running as they are designed to work locally on your machine.
We’ve also noted a similar issue with couple of other integrations, like Pylance as mentioned by @adam-wolfe. Fortunately, as some users have discovered, there are a few workarounds. It might be worth trying to add the USS folder to your VS Code workspace that should fix the problem.
We understand that this is not an ideal solution at the moment, and we are looking into how we can improve the experience.