Skip to main content

SonarQube–Configure coverage exclusions

Code reviews are one of my daily activities. To help me streamline the process, I like to use the help of static code analysis tools like NDepend and SonarQube.

While looking through the SonarQube logs for a specific project I noticed a large list of issues in a set of Javascript files. These Javascript files were external libraries (like jQuery) that were imported into the project and not created by the dev team. Fixing these issues would only be possible by sending a pull request to the library maintainers.

To stop the pollution of our SonarQube logs, I decided to exclude these files from the log analysis.

Here are the steps:

  • Browse to your SonarQube dashboard.
  • Login as an administrator.

image

  • After being logged in, you can go to the Administration tab on the project level.

image

  • Select Analysis Scope from the Category list.

image

  • Go to the Files tab and add one or more Source File Exclusions.
    • In our case we want to exclude the Scripts folder in our web project, so we add Scripts/** to the Source File Exclusions
    • IMPORTANT: Source File Exclusions are case sensitive. First time I entered scripts/** which had no effect.

image

  • Source File Exclusions are executed on the project level and applied for each csproj file individually:

2018-09-03T06:55:30.4158415Z INFO: -------------  Scan MTIL.Web
2018-09-03T06:55:30.4158415Z INFO: Base dir: D:\b\4\agent\_work\35\s\MTIL.Web
2018-09-03T06:55:30.4168180Z INFO: Working dir: D:\b\4\agent\_work\35\.sonarqube\out\.sonar\MTIL_MTIL_C301B249-2F5F-4264-B23F-FC169C8E7397
2018-09-03T06:55:30.4207240Z INFO: Source encoding: UTF-8, default locale: en_US
2018-09-03T06:55:30.4207240Z INFO: Index files
2018-09-03T06:55:30.4207240Z INFO: Excluded sources:
2018-09-03T06:55:30.4207240Z INFO:   Scripts/**
2018-09-03T06:55:30.4431835Z INFO: Analyzer working directory contains 5 .pb file(s)
2018-09-03T06:55:30.5886820Z INFO: 40 files indexed
2018-09-03T06:55:30.5886820Z INFO: 14 files ignored because of inclusion/exclusion patterns
2018-09-03T06:55:30.5964940Z INFO: Quality profile for cs: Sonar way
2018-09-03T06:55:30.6238360Z INFO: Sensor Lines Sensor
2018-09-03T06:55:30.6248125Z INFO: Sensor Lines Sensor (done) | time=1ms
2018-09-03T06:55:30.6248125Z INFO: Sensor SCM Sensor
2018-09-03T06:55:30.6736375Z INFO: SCM provider for this project is: git
2018-09-03T06:55:30.6746140Z INFO: 1 files to be analyzed
2018-09-03T06:55:31.7077510Z WARNING: WARN: Missing blame information for the following files:
2018-09-03T06:55:31.7116570Z INFO: 0/1 files analyzed
2018-09-03T06:55:31.7184925Z INFO: Sensor SCM Sensor (done) | time=1034ms
2018-09-03T06:55:31.7184925Z INFO: Sensor C#
2018-09-03T06:55:31.7194690Z INFO: Importing analysis results from D:\b\4\agent\_work\35\.sonarqube\out\6\output-cs
2018-09-03T06:55:31.7194690Z WARNING: WARN:   * D:/b/4/agent/_work/35/s/MTIL.Web/ErrorHandler/AiHandleErrorAttribute.cs
2018-09-03T06:55:31.7194690Z WARNING: WARN: This may lead to missing/broken features in SonarQube
2018-09-03T06:55:31.7809885Z INFO: Importing Roslyn report
2018-09-03T06:55:31.8151660Z INFO: Sensor C# (done) | time=155ms
2018-09-03T06:55:31.8151660Z INFO: Sensor C# Unit Tests Coverage Report Import
2018-09-03T06:55:31.8151660Z INFO: Sensor C# Unit Tests Coverage Report Import (done) | time=0ms
2018-09-03T06:55:31.8161425Z INFO: Sensor C# Integration Tests Coverage Report Import
2018-09-03T06:55:31.8161425Z INFO: Sensor C# Integration Tests Coverage Report Import (done) | time=0ms
2018-09-03T06:55:31.8161425Z INFO: Sensor C# Unit Test Results Import
2018-09-03T06:55:31.8161425Z INFO: Sensor C# Unit Test Results Import (done) | time=0ms
2018-09-03T06:55:31.8171190Z INFO: Sensor Zero Coverage Sensor
2018-09-03T06:55:31.8415315Z INFO: Sensor Zero Coverage Sensor (done) | time=14ms
2018-09-03T06:55:31.8415315Z INFO: Sensor Code Colorizer Sensor
2018-09-03T06:55:31.8415315Z INFO: Sensor Code Colorizer Sensor (done) | time=2ms
2018-09-03T06:55:31.8425080Z INFO: Sensor CPD Block Indexer
2018-09-03T06:55:31.8425080Z INFO: DefaultCpdBlockIndexer is used for cs
2018-09-03T06:55:31.8718030Z INFO: Sensor CPD Block Indexer (done) | time=1ms

Labels:

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...
Read more

Cache stampede: when our cache turned against us

While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...
Read more

A complex system designed from scratch never works

A few years ago, I worked as an architect on a big mainframe rewrite. I still count it as one of my failures. Not because the technology was wrong, but because I couldn't convince the management team to simplify the approach. Years later, the organization is still struggling to get the new system up and running. I left the project at the time, because I couldn't put my name behind an approach that would take very long and cost a lot of money without a working system to show for it along the way. Gall’s Law That memory keeps coming back to me, because it's a textbook case of Gall's Law playing out in real life. Gall's Law , from John Gall's Systemantics , states it plainly: A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works, and it cannot be patched to make it work. You have to start over with a simple system that works. What does that mean in practice,...
Read more