We have setup pull request analysis for C# .Net code. It is observed old code(unmodified) is being considered for analysis which is not expected, this is blocking us from using quality gates.
The new code condition is set based on the “number of days” condition which is set to 1.
Even then the PR/short branch analysis reports issues that are present in old code (which are not updated\edited as part of the pull request), because of this issue we are unable to enable quality gates.
Following tasks are used in the azure devops pipeline:
Prepare analysis for sonar cloud
Run code analysis
Publish quality gate result
ALM used: Git in Azure DevOps CI system used Azure DevOps
Languages of the repository: C# .Net
This is an example SonarQube pipeline configuration which is executed on every merge to the master branch.
Example pipeline steps
Steps:
Node is installed for building purposes
Prepare analysis is initiated which downloads necessary for scanning, configurations and rulesets
Nugget package manager is installed
Nugget restore is initiated
Solution is built (important step)
Code analysis is checking every .cs file contained in the solution previously built
Strict quality gate are the scan results
Custom build step which breaks the pipeline if quality gate has failed
This might be obvious but make sure you are building the C# solution in between the Prepare analysis on SonarQube and Run Code Analysis in order to provide updated code that SonarQube will analyze.
The "Get results from SonarQube" step is a powershell script that calls the SonarQube API to get the quality gate results of the scan initiated in order to fail if issues have been found.
Related
I configure Azure pipelines with react native. I need to analyse the code using SonarQube. Builds are succeeded.But SonarQube shows no issues. The Publish Quality Gate Result shows ['No analysis found in this build! Please check your build configuration.']
I'm using gitlab-ci pipeline, it will run a new docker container with following commands:
mvn --batch-mode verify sonar:sonar
-Dsonar.analysis.mode=preview
-Dsonar.gitlab.project_id=$CI_PROJECT_ID
-Dsonar.gitlab.commit_sha=$CI_COMMIT_SHA
-Dsonar.gitlab.only_issue_from_commit_file=true
-Dsonar.gitlab.ref_name=$CI_COMMIT_REF_NAME
-Dsonar.host.url=xxx
-Dsonar.test.inclusions="/src/test/java/**/*.java"
-Dsonar.login=xxx
It becomes quite slow for my project, almost run for 20mins.
I found it will scan all files instead of only the commited files.
Is there anything wrong with my configurations?
In some past SonarQube versions we changed the preview mode to only scan changed files. But it has some drawback, like not being able to properly detect cross file issues.
In recent SonarQube versions, the preview mode is deprecated in favor of pull request analysis. But even this PR analysis feature is scanning all files, for the same reasons (cross file issues, coverage measures, duplication detections, ...).
We stopped trying to do partial analysis, and are instead trying to optimize full analysis duration. How big is your project? Is SonarQube analysis time long compared to your regular build (compile + tests)? If yes, then I suggest you report you case on the SonarSource community forum.
I am triggering a Sonar analysis from Jenkins whenever a user commits any change to any branch of my project. In SonarQube I see the project analysis result, and quality gate status, for the most recently run analysis. It only shows the most recently run analysis for a given project.
How can I see a 'history' of previous analyses that were run prior? Specifically I would like to see the coverage from before and the where in the codebase specific 'critical' issues triggered a quality gate failure. Basically I want a historical snapshot of the 'project overview' page for each time the analysis is run. Since I am triggering the analysis from different branches I need to be able to differentiate an analysis of Branch A vs. a previous analysis of Branch B.
If you use SonarQube up to version 5.6: Use the Sonar Timeline Plugin, which allows you to add a graph to your dashboard.
If you use SonarQube version 6.5 or later (to be released in August 2017): Get feature rich history graphs out of the box (no plugin required)!
It looks like you have to make a custom dashboard and add a history widget. It looks like it shows you just the times the gate changed (which i guess is what I should have expected) for example the project I tested with only changed status 3 times so even though I asked for 10 columns it only showed 3.
This is on the Sonar homepage for your project, not the sonar widget in jenkins fyi
We are using scripted build in our VSO environment and integrate with SonarQube, using the SonarQubePreBuild and SonarQubePostTest tasks.
Especially since SonarQube version 5.2 we experience that builds are always succeeding as long as SonarQube succeeds in generating the report.
For VSO Git pre-commit policies we have configured pull requests to start a build including SonarQube analysis.
However the configured Quality Profile is not met for the project, the build seems to succeed since SonarQube was able to do the actual analysis.
...But we want the build to fail....since quality conditions are not met.
We could add an additional custom (powershell) task to retrieve the results from the SonarQube instance, but what if we are running in preview mode and reports are not stored in the SonarQube database?
Before 5.2 you could use the Build Breaker Plugin to have the build fail in VSO. But the Plugin is no longer compatible with 5.2 and is planned to be included in Sonar Core in 5.4.
See this question for details.
I'm trying to run a preview analysis for a (Java) project of ours with SonarQube 5.1.1. I am able to get a local report generated, however I get no coverage data, and I also get the message [INFO] [XX:YY:ZZ.ZZZ] Build Breaker plugin is no more supported in preview/incremental mode.
If I check here, the page says that Starting with SonarQube 5.1, the Build Breaker plugin does not work any longer in the preview & incremental modes..
I'm confused - I thought that for continuous inspection one needs the build breaker plugin. Is that no longer so? Has the concept in SonarQube changed?
Why am I not getting coverage data when running a preview analysis?
I don't know where you've read this, but continuous inspection is not specifically related to the preview/incremental mode nor to the build breaker plugin - it's not even related to SonarQube (even though it has been pushed by SonarSource from the very beginning).
Here are the key points:
Continuous inspection is about analyzing your code as often as you can in order to monitor (and eventually improve) the quality of your code. Whatever the tool.
On SonarQube, this means running analyses that will push information on the server so that you can monitor what's going on and take the required actions for your application portfolio.
Obviously, when you are a developer, you'd like to manage those issues early, before they even get pushed to the source code repository. But experience tells us that preventing any code push because of issues is a bad pattern - because some issues might be false-positive or not relevant in the context (and still you want - and have the right, to push your code). This is why we feel that the build breaker plugin is not aligned with all this, and it will be replaced in upcoming versions of SQ by native features that match better these concepts:
Very efficient code analysis to display issues in the IDE at the speed of light - but without computing metrics
Preview mode that will compute everything and make it possible to check quality gate before pushing code to the source code repository - without impacting the results on the server
and in this case, using some specific information found in the logs, it will be possible for a CI to fail a build