what are you trying to achieve: I am trying to view findings from the ESLint (Typescript) report file in Sonarqube.
what have you tried so far to achieve this: See below
I have tried 3 ways to generate and import the ESLint report file into SonarQube, but none of them will show any results in SonarQube. Method 1:
Lint Command: lint --format json -output-file <report path>/eslint_report.json
SonarQube Properties in the Jenkinsfile (these are known to be found and used):
Method 3:
[Using a custom formatter and the format from Generic Issues Import Format ]
Lint Command: lint --format ./myformatter.js -output-file <report path>/eslint_report.json
I am sure that the Jenkins sonar task is able to find and read the file.
Trying to import a json file created by ESLint with the “sonar.externalIssuesReportsPaths” property generates errors.
Trying to import a json file created by the custom formatter with the ESLint with the “sonar.typescript.eslint.reportPaths” or “sonar.eslint.reportPaths” property generates errors.
Keeping the pair in sync generates no errors on import.
I can open the Sonar link from Jenkins which takes me straight to the Pull Request branch.
In the SonarQube UI:
There are no Lint issues or reference to the imported ESLint report under any of the tabs (Overview, Issues, etc.) \
I have looked at the generated ESLint JSON files in the Jenkins Workspace (both versions) and there are multiple (Type: CODE_SMELL; Severity: INFO) issues.
I have even hi-jacked the custom formatter so that the issues are written out as: Type: BUG; Severity: MAJOR.
This does not work either.
What needs to be done in order to see the Imported ESLint issues?
The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.
I am waiting for access to our sonarqube server (and its logs).
However, after a lot of attempts, I have a much better question:
How do I get SonarQube to display issues for code problems (identified by ESLint) for code that was not changed?
I was able to get all of the issues in the generated ESLint input .json file to display (In the “Issues” tab), if and only if the current set of changes ALSO changed the source code that corresponded to the ESLint input file data.
I was also not able to get SonarQube to use the input Json data applied to the Overall codebase.
Is there a way that the input ESLint input file data can be applied to the entire code base?
Just for the record, I was asking for the CI-side logs, not server logs. But moving on…
It seems that you’ve got analysis correctly reading your ESLint issues report. The question of where issues show up sounds like it has something to do with PR / New Code analysis.
Can you share some detail about how you’re analyzing? Also, when issues are missing from overall code, do you see issues from native rules in the code? Or are all issues missing?
Could you share some screenshots? I’m struggling a bit to understand quite what you’re experiencing.
Thank you for responding so quickly, following on this issue, and trying to assist me.
Unfortunately, I have been informed that providing screenshots, logs, etc. is not something that I have authorization to do.
However, I think that what I am seeing is SonarQube’s default behavior.
My “Revised” question:
Is there a way to direct SonarQube to display an entry in the “Issues” Tab for every Lint finding in the Json file that is generated by an ESLint scan of the source code (Typescript)? \
SonarQube can read and import the ESLint Json file without issue.
It will display ESLint findings for changes that exist in the committed branch.
SonarQube will not show findings that are in the input ESLint Json file unless there is a corresponding code change in the committed branch.
This is the behavior that I would like to be able to override, so that all issues/findings in the input file that was generated by ESLint (regardless of changes to the source code) are also displayed.
Again, I apologize for not being able to comply with sharing sever logs, etc.
However, I think that I was able to find the reason for what the SonarQube Analysis is (or in this case is not) showing me with regard to the ESLint Json input file. \
Each SonarQube project has a new code definition (NCD), that is, a setting that tells SonarQube which part of the code is considered new code. When you run an analysis, SonarQube uses the new code definition to identify new code, then highlights issues in the new code.
There is a special info box on the page:
For analysis of pull requests and branches, the new code definition is not used. Instead, the new code issues are those introduced by the pull request or the branch itself.
Can you confirm whether these statements are correct:
SonarQube needs to detect the ESLint finding locations as “New Code” in the branch in order to show the findings from the ESLint Json report as an Issue in its display.
1.1. i.e. the findings in the ESLint Json file are not displayed, because there were no changes to the source code on the branch.
In order for SonarQube Issues tab to display all of the findings from the ESLint Json file, it would be necessary to have SonarQube Analysis to detect all (Typescript) files as “New Code”.
2.1. [This is a guess] To implement this, it would be necessary to disable the comparison between the working branch and main/master so that ALL code is “new”.
The ESLint Json file is external to SonarQube. Its findings will not be integrated or carried forward when the Branch is merged back into Main.
It’s not clear to me where you’re seeing that. For PRs only the changed code is reported on. For branches, all code will be reported on, and what shows up as New Code depends on the branch’s New Code definition.
For your numbered statements, 1 and 2 seem like the same thing to me, so I’ll answer them together: They are only correct if we’re dealing with a PR. For a branch, all issues should be reported.
Presumably you’re feeding the same/similar report into the analysis of Main, so there’s no question or worry about them being “carried forward”.
