I would like TeamCity to run my mSpec tests and report on the code covered by the tests.
I would also like TeamCity to report that a build has failed if code coverage in certain namespaces doesn't meet a threshold (e.g. MyProduct.ImportantStuff must be 100%, but MyProduct.LegacyStuff must be [23% or whatever it currently is to ensure we don't add new stuff without covering tests].
I initially looked at dotCover as it's integrated into TeamCity. I have since been looking at OpenCover as I couldn't get TC to fail the build on low coverage.
I got OpenCover working but I would still like to know (as I'm sure a lot of people would) how to get TC to fail a build if code coverage is too low.
Are you using the latest TeamCity, ie version 7?
When setting up a build configuration you can specify this:
There are lots more options in the dropdown related to code coverage. You can also force your build to fail if you're using some other code coverage tool.
For example you can echo a line to the console that will then be picked up by teamcity :
##teamcity[buildStatus status='FAILURE' text='something failed']
see official docs on this here
Related
We are starting to implement code coverage in our CI process and my task is to examine NCover from this perspective.
Specifically, we have SonarQube and a CI build in Azure DevOps that runs the unit tests and reports the coverage to SonarQube as described in https://docs.sonarqube.org/latest/analysis/scan/sonarscanner-for-azure-devops/
Currently it works with the DotCover command line tool.
I would like to check NCover. While googling for it I came across this cheerful page - https://www.ncover.com/support/docs/extras/sonar-integration and sure enough I clicked the link to the respective Jira issue - https://jira.sonarsource.com/browse/SONARCS-653 Oops. Closed with Won't Fix.
According to https://docs.sonarqube.org/latest/analysis/coverage/ only VS Coverage, DotCover and OpenCover format are supported. So, if NCover is supported, it would be through the Generic Test Data format or if NCover knows to produce coverage results in one of the other 3 formats.
So far I do not see how NCover can play with SonarQube, but maybe I am missing something here.
Anyone?
Got an answer from an NCover representative. There is no integration between SonarQube and NCover. Full stop.
I have several java projects with no unit test cases. When I try to analyse these projects using SonarQube I am unable to get unit test code coverage because it doesn't have any test cases. As per my research I saw that I can force it to show it as zero if there are no unit test cases. The official Jacoco Java documentation mentions sonar.jacoco.reportMissing.force.zero=true.
My SonarQube analysis will be done using maven builds and SonarQube 5.6.6 and sonar-java 4.11.0.10660.
How can I set this parameter in maven so that it can show as zero unit test cases in my coverage?
From version 6.2 SonarQube does this automatically where the behavior is supported by the analyzers. Before that version, availability of the feature is spotty and not entirely reliable. For best results you should upgrade SonarQube.
That said, you can set that property on the analysis command line like so:
mvn sonar:sonar -Dsonar.jacoco.reportMissing.force.zero=true
Or by setting a property in your pom, as shown in the docs
Update 16 Dec 2019
Most language analyzers now calculate Executable Lines, so files omitted from the coverage report are included in calculations anyway. But that only kicks in if you provide coverage reports. No coverage reports -> no coverage metrics at all.
Since we updated to SonarQube 6.2 it seems code coverage plugin got merged in the core.
It shows red flags everywhere and I can’t find how to turn it off, we do not use code coverage.
You don't specify what language(s) you're analyzing. I'll assume Java and/or JavaScript. Starting from 6.2, SonarQube supports "force coverage to 0", which marks as uncovered executable lines in files that don't show up in any coverage reports. (That's assuming the underlying code analyzers support the feature, and Java and JavaScript already do.) The purpose is to have a more accurate picture of what's missing when you actually are using unit tests. Without this feature, it's impossible to tell whether a file that's omitted from coverage reports is missing because it has no executable code or because there are no tests on it - even when there should be.
Since you're not using unit tests (really?) you can exclude all the source files in your project from coverage calculations via the UI: Administration > Analysis Scope > Coverage Exclusions. A pattern value of **/*.* ought to do it for you.
Code coverage feature is in SonarQube misleading. To turn this off:
Under Quality gates create new or copy existing profile.
There delete Coverage metric
SonarQube Version: 9.2
Does Sonar offer any way to raise alerts and fail a build when the trend for certain metrics is bad?
Background: In our legacy project using a static threshold for example for code coverage ("red alert when coverage is below 80%") does not make much sense. But we would like to make sure that the coverage does not go down any further.
Please do not give any advice on lowering the bar by using a less restrictive rule set. This is no option in our case.
There is a build breaker plug-in that will fail the build if you breach a Warning or Error threshold setup in the quality profile.
Plug-in details are here:
http://docs.sonarqube.org/display/PLUG/Build+Breaker+Plugin
Not aware of any functionality that enables you to a metric trend.
We use Sonar as the second last step in our release process. The build breaker ensures that releases do not breach predetermined quality criteria.
We tried exactly the same, using the build breaker plugin. After a while, it showed to be too unflexible (and configuring Sonar is a mess), so we moved from sonar to Jenkins/Hudson plugins like Cobertura (for code coverage) or PMD for code style:
https://wiki.jenkins-ci.org/display/JENKINS/PMD+Plugin
https://wiki.jenkins-ci.org/display/JENKINS/Cobertura+Plugin
With these plugins, very fine-granular settings are possible, to set for example the build to yellow at <70% code coverage or to red by <50%; even the weather-symbol for each build is setable.
In the meanwhile we scripted our own buildbreaker that gets excecuted within our build. We use Groovy to query the REST API of Sonar to retrieve a certain set of metrics (including their historical values). The retrieval of metrics is provided by a build plugin that is provided for our whole division.
Each team can parameterize their build with a set of rules regarding those metrics that have to be verified for their project. Of course, the rules are also provides as Groovy snippets :-)
Typical are:
Number of (major|critical|blocker) violations is less or equal than in previous build
No new duplicates
Coverage not lower than in previous build
Bad findings can then be used for breaking the build or just for reporting.
I've seen a number of posts on making a Maven-backed Jenkins build fail for a given project if a coverage threshold isn't met i.e. coverage must be at least 80% or the build fails.
I'm wondering if there is a way to configure Jenkins to fail a build if the coverage is lower than the last build i.e. if the coverage for build N is 20%, and N+1 is 19%, then the build fails. I don't want to put in an explicit threshold, but I want the coverage to stay steady or get higher over time.
I haven't tried it, but assuming you are using maven cobertura plugin, I believe it can be configured to fail as documented here. Would jenkins not honour the failure?
I also see an open feature request for this.
Save last coverage percentage on the side. Use Groovy script (run via Groovy Plugin) that taps into Jenkins Java API to compare current coverage level with previous one and fail the build if it drops. If you seriously decide to go this way I can provide more details and code samples.
Since the 1.6 version of Cobertura plugin, the issue has been fixed, and a new option appeared that allow the plugin to make the build failed if coverage is lower than previous build.
This should be configurable in the configuration section of the plugin, that calculates the coverage. E.g. for the PMD plugin you can configure limits for unstable or failed build on the Job configuration page in the section "Build settings".
In NCover I specify a certain percent through a config file. You could create a python script (or similar to alter that value if you wanted). Other than that I do not think there are any config variables