Tracking SonarLint Usage via SonarQube

I would like to see SonarQube reporting which users are using SonarLint and (ideally) what version the are using.

I know that I have a some developers who just recently started using SonarLint (after I nagged them) and know that once they tried it they became instant converts, finding it really useful. I also have strong reason to believe that some developers are not using it… but have no way of tracking usage and identifying them, or knowing who is out of date, etc.

This is where I think that SonarQube Server (or Cloud) could help out by providing some metrics. It should be possible to identify SonarLint connections via HTTP user-agent headers, right?

You should already see that in /logs/access.log with the concrete Sonarlint version if the
notifications are on, which is default for a Sonarlint Sonarqube connection i believe.
Sonarlint checks every 5 seconds.

i.e this is a log entry in access.log - - [22/Apr./2021:00:00:47 +0200] “GET /api/developers/search_events? HTTP/1.1” 200 13 “-” “SonarLint Eclipse”

We are using an Apache reverse proxy and use this accesslog pattern

#sonar.web.accessLogs.pattern=%h %l %u [%t] “%r” %s %b “%i{Referer}” “%i{User-Agent}” “%reqAttribute{ID}”
sonar.web.accessLogs.pattern=%i{X-Forwarded-For} %h %l %i{X-Forwarded-Login} [%t] “%r” %s %b “%i{Referer}” “%i{User-Agent}”

Should also work without reverse proxy.

This is the configuration in Sonarlint, i.e. in Eclipse


Hello @msymons, thanks for your suggestion! This is an interesting topic, and indeed it is one we would like to take into account for our roadmap. Thus it is great to see you are interested to get this kind of SonarLint usage information into SonarQube and SonarCloud.
One question to better understand your scenario: would you like to identify each individual developer not using SonarLint (or at least, not connecting into SQ with SonarLint) so that you can suggest it to them, or you “simply” want to have an overall idea about the share of developers using/not using SL?

We are not working yet on the topic, so for the time being I cannot anticipate the exact scope we want to cover, nor I can share any timeline, but be assured we will take your feedback into account, and we will share some update in this thread when we will work on the topic.

@Rebse , thanks for the info. We have an nginx proxy in front of SQ (and all our servers) so I’ll need to check configuration no matter whether I pull info from logging or end up getting some nice built-in SQ reporting.

@Marco_Comi, I definitely want to be able identify exactly who is (is not) using SonarLint so that I know who to help.

We’ve had pull-request decoration working just great for a few months now (the introduction of the wizard sure helped sort out the last problems we had with that) and thus I am now seeing projects that may have a lot of historical technical debt have decoration on merged PRs showing that they were merged with zero code smells (etc).

However, I also have the SQ emails recording that PRs are very often being created whilst still have problems. This is where I believe SonarLint would help. Addressing problems earlier should improve productivity and result in less time elapsing between PR creation and PR merge.

And that’s where the need for reporting come in. When I know someone is NOT using SonarLint then I can get them to start. When I know someone IS using Sonarlint then I can check if there is a problem should I see that PRs are still getting created whilst having any sort of QG problem, etc. This latter does not change the end result (given that the devs are already fixing everything) but it’ll make it easier to get there…

1 Like