How to speed up SonarCloud analysis so that it fits on travis?


since a few time, the sonar-scan run got so long that our travis builds systematically timeout. We had to disable the tests of our library to remain under the time limit of travis.
Here is a log of today:
Here is another log, from 2 months ago:

In the old build we had:

INFO: 314 compilation units analyzed
INFO: 318 compilation units analyzed
INFO: PCH: 0 + 0 + 0 , 218883 - 0 - 0 - 0
INFO: FS: 6269057 lookups
INFO: PPH: 1140 files, 19216892 bytes, 107920 hits, 109060 queries
INFO: Sensor CFamily [cpp] (done) | time=464629ms

while in the recent build, one can read:

INFO: 473 compilation units analyzed
INFO: Sensor CFamily [cpp] (done) | time=1625285ms

So, the analysis of our C++ files went from to less than 8 minutes to about 27 minutes in two months. This was not the most active development period in our project, so I’m a bit surprised.

We tried several tricks to speed up the things and keep under the travis time limits:

At the end, we had to disable our tests from the travis build to remain under the time limit. This is really unfortunate as it prevents us from getting any coverage information.

Is there another way to speedup the sonar-scan, or do we have to move away from travis? Is it even possible to run sonar-scan out of travis (e.g., on circle-ci or framagit runners)?

Thanks in advance for your help, and many many thanks for this incredible tool. That’s really unique!


1 Like

Hi Martin,

First of all thank you for the warm words :heart:

I believe that the following answer also answers all your questions, please have a look at it and let us know whether it does answer or not:


1 Like

Hello Evgeny,

thanks for your quick answer!

As I understand things, the best thing we can do is to move away from travis to run our tests. Am I right? If so, I’ll give it a spin in the near future. We do have other possibilities to host these tests.

Thanks again, Mt.

Yes - your understanding is correct.