@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…