Sonar Client/Server Architecture

Fleeting

This is what I guessed.

1. on a CI or the computer of a developer, sonar-scanner is run. It scans the code, gets the SCM annotations of the code (among other things the date of the last commit that brought each line) and sends the analyses and annotated code to the server¹, associated with a sonar.projectVersion value. Hereafter, we call this analysis the current version. Its date is either the date of scan or whatever you put in the projectDate property.
2. the server stores the in a stack. The order of the sent analyses impacts how sonar will behave, so don’t send a past analysis (with sonar.projectDate) and rather create a new project from scratch.
3. the server finds a date after which it considers the code as being new,
   • either using a number of days from the date of the current version,
   • or using a fixed date
   • or finding another analyses as base and using its date
     • if using the new code as being from the previous version, it checks the most upper analysis of the stack whose projectVersion is different from the current version ².
     • if using the new code as being from a fixed version, it find from the top of the stack the last analysis with that version.
4. the server now has an interval of time (two dates) that define the temporal interval of new code,
5. in the current version analyses, sonar finds all the lines whose annotation are in this interval -> those become the new code.

Notes linking here

• ambiguity in computing the new code in sonarqube

Permalink