I have a web app project where the quality is measured under sonarqube.
As i'm dealing with an external code within my project files
Recently i have had some issues appearing due to that exetrnal code and which i'm not focusing on its quality :
So i wanna just delete the issue to appear from my sonar dashboard (which looks like the following):
The solutions that i have had where not really usefull , as :
i was suggested to change the level of the rule itself from "issue" to "info" :
And of course that seems to be not usefful because , i won't affect the rule itself
the second suggestion was to use the :
#SuppressWarnings decorator in my blocks of code where the issues appeared ; : for example use it under classes or methods or even fields
-> this method results in adding some code to my extarnal code and that won't be also good as i'm not even having the permission to do it.
I wanna just the simpliest solution to delete the issue from the sonar dashboard , just suppress it from the SonarQube interface , strangely it seems that there is no a direct way to do it :
Any better ideas ??
The easiest way is excluding external code from the report with narrowing the focus feature.
Just add to your sonar-project.properties file path pattern to exclusion, for example
# Exclude all classes ending by "Bean"
# Matches org/sonar.api/MyBean.java, org/sonar/util/MyOtherBean.java, org/sonar/util/MyDTO.java, etc.
sonar.exclusions=**/*Bean.java,**/*DTO.java
# Exclude all classes in the "src/main/java/org/sonar" directory
# Matches src/main/java/org/sonar/MyClass.java, src/main/java/org/sonar/MyOtherClass.java
# But does not match src/main/java/org/sonar/util/MyClassUtil.java
sonar.exclusions=src/main/java/org/sonar/*
If you're not interested some issues because it's not your code, then you should not have SonarQube analyze that code. According to the SonarQube documention:
We recommend that you exclude generated code, source code from
libraries, etc.
You should check in particular the following settings in the same documentation page:
sonar.sources
sonar.exclusions
These settings will be taken into account the next time you run an analysis.
Related
I am trying to find a portable way to produce code annotations for GitHub in a way that would avoid a vendor-lockin.
Mainly I want to dump annotations inside a file (yaml, json,...) during build process and have a task at the end that does transform this file into github annotations.
The main goal here is to avoid hardcoding support for github-annotation into the tools that produce them, so other CI/CD systems could also consume the annotation-reports and display them in their UI.
linters -> annotations.report -> github-upload
Tools like flake8 are able to produce output in parsable format file:line:column: message, but I need to know if there is any attempt to standardize annotations so we can collect and combine them from multiple tools and feed them to the CI/CD engine.
Today I googled up what the heck those "Github Action Annotations" are all, and this was among the hits:
https://github.com/marketplace/actions/annotations-action
GitHub action for creating annotations from JSON file
As of now that page also contains:
This repository uses npm packages from #attest scope on github; we are working hard to open source these packages.
Annotations Action is not certified by GitHub. It is provided by a third-party and is governed by separate terms of service, privacy policy, and support documentation.
I didn't try it, again, just a random google hit.
I am currently using https://github.com/yuzutech/annotations-action
Sample action code:
- name: Annotate
uses: yuzutech/annotations-action#v0.3.0
with:
repo-token: ${{secrets.GITHUB_TOKEN}}
input: ./annotations.json
title: 'Findings'
ignore-missing-file: true
It does its job well but with one minor defect. If you have a findings on a commit/PR you get to see the finding with a beautiful annotation right where you need it. If you re-push changes, even if the finding persists, the annotation is not displayed on later commits. I have opened an issue but I have not yet received an answer.
The annotations-action mentioned above has not been updated and it does not work with me at all (deprecated calls).
I haven't found anything else that worked exactly as I wanted it to.
Update: I found that you can use reviewdog to annotate based on findings. I also created a GitHub action that can be used for Static Code Analysis here https://github.com/tsigouris007/action-semgrep-reviewdog. You can visit the entrypoint.sh file and check how I piped the custom output to reviewdog utilizing jq.
I want to add customized java rules in sonarqube. I have googled it and found that we need to make a pluggin for that. But can't find any proper link describing to make the rule. Any help would be appreciable.
You can follow "Writing Custom Java Rules 101", which describes how to make a sonar-packaging-maven-plugin artifact.
When implementing a rule, there is always a minimum of 3 distinct files to create:
A test file, which contains Java code used as input data for testing the rule
A test class, which contains the rule's unit test
A rule class, which contains the implementation of the rule.
As mentioned in "Custom Rules for Java", To go further, you can explore a sample plugin containing other custom rules.
This project can be browsed or downloaded.
We utilize the pipeline and after the build completes successfully we are running the following:
bat "mvn sonar:sonar -B -s ${buildSettings} -Dsonar.analysis.mode=preview -Dsonar.skipDesign=true -Dsonar.report.export.path=sonar-report.json"
sonarToGerrit(severity: 'Major', postScore: true, category: 'Code-Review', newIssuesOnly: true, issuesScore: '0', noIssuesScore: '0', changedLinesOnly: true)
The below build log shows that it found a good number of issues but yet the issues to be commented is 0.
Build log
Other posts suggest that it may not be finding the report but I don't believe it's the case as it found a number of issues. Any pipeline configuration advice would be much appreciated.
We are using Sonar Gerrit plugin version 2.2.1, Gerrit Trigger 2.27.3 and Jenkins Enterprise version is 2.60.3.1.
The most common case regarding to your question is related to the fact that SonarQube checks the whole project, regardless of amount of changes that were done in particular change. When creating a new report, it compares a result with a result that is stored to it's database (with previously found issues that were found in a mode other than preview). Thus sonar marks as new all the issues that it was not aware about before (and if you don't store this information in SonarQube at all - all the issues will be marked as new). But sonar-gerrit plugin can only post issues to the files that were affected by the change it is verifying. So, even if you set to "false" the settings "newIssuesOnly" and "changedLinesOnly", all the issues in files not affected by the change will be ignored.
Shortly, check that the issues marked with "isNew"="true" in your sonar report were actually changed (for changedLinesOnly=true) or located in the changed files (for changedLinesOnly = false) in the commit you are trying to check.
Another possible reason is the project configuration settings. If your files are part of a submodule, you'll need to include the submodule name to project base directories set. Or you may want to try a feature "allow auto match" instead. The feature tries to match SonarQube modules to Gerrit names automatically (available since 2.1).
Not related to your question advises regarding your pipeline code:
At the moment settings recognition for severity (and other enum values) is case-sensitive. In fact, the plugin ignores your "Major" setting as it cannot recognize it, and replaces it with default "INFO" value.
Another thing, I don't see why do you set your "postScore" to true as you set "issuesScore" = 0 and "noIssuesScore"=0. You can just set postScore=false and skip these settings along with "category" for sake of simplicity.
Also, if you use the version of plugin above 2.0, be aware that API has slightly changed and now uses the next structure:
sonarToGerrit (
reviewConfig: [
issueFilterConfig: [
severity: 'MAJOR',
newIssuesOnly: false,
changedLinesOnly: false
],
noIssuesTitleTemplate: 'Your text here',
someIssuesTitleTemplate: 'Your text here',
issueCommentTemplate: 'Your text here'
]
)
Though your code should also work (plugin does support previous versions), there is a bigger chance that there may be a bug.
I am also facing the same issue with Sonar-Gerrit jenkins plugin. Downloaded it from Jenkins plugins site.Using Sonar-Gerrit plugin 2.2.1, and analysing sonar scan against jenkins workspace.
For a sample,have changed just one file and provided the project base directory to the path of that file, and ran the sonar analysis in issues mode.
Issues are not loaded in Gerrit with logs
Report has loaded and contains 759 issues
Issues to be commented: 0
Issues to be involved in score calculation: 0
Review has been sent
How can we identify the most common types of issues in a project in our current code base.
We have recently upgraded from Sonar 4.5 to 5.1
In 4.5 we used to view the issues list in a specific project, and the issues were grouped by issue type. For instance in one project the rule "Use a logger to log this exception" might be the most common critical rule with 45 violations. We could then use that information to drive improvement efforts.
In 5.1 we are now presented with a long list of issues with no apparent way of group them.
The ability to see what type of violation was most common was also useful in allowing us to see where best to direct our efforts in terms of remedial action.
You can do that easily on issue page of your project : just click on the rule facet and you should have the list of most violated rules.
See http://nemo.sonarqube.org/issues/search#resolved=false|projectUuids=b38e4f29-df5f-491e-9118-a0a4f5cda406 for instance and click on "Rule" facet.
To group issues by type you can use the rule facet in the web interface.
But you will have only the 15 more frequent rule violations.
Another possibility, is to use the web api directly with a comma separated list of the rules you are interested in.
GET http://localhost:9000/api/issues/search?rules=squid:S1905,squid:UndocumentedApi
Another solution, if you really want this feature is to customize Sonarqube by changing:
private static final int DEFAULT_FACET_SIZE = 15;
in StickyFacetBuilder.java
You can also suggest a new feature here: https://community.sonarsource.com/c/suggestions
There is a Rule filter on Issues tab.
Our organization is using SonarQube for managing code quality as well as Docco for handling production of documentation from code comments.
We're running into a conflict between including things like method names in comments for Docco and the 'Sections of Code should not be "commented out"' rule in SonarQube.
Are there any known best practices to get SonarQube to ignore code in comments that are for documentation (even better if for Docco in particular) while still catching old code that has been commented out instead of being removed?
The rule "Sections of code should not be commented out" could be simply disabled in the quality profile related to your project.
sharing this as it could help if anyone having similar issue.
one way is to comment the code along with additional lines or single quote to ignore that line which worked for me
example
# print("sample")
you can write this as
# ' print("sample")