Hello,
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: https://api.travis-ci.org/v3/job/475311596/log.txt
Here is another log, from 2 months ago: https://api.travis-ci.org/v3/job/453796591/log.txt
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:
- Build our library with
make -j4 - Add
sonar.cfamily.threads=4in our sonar-project.properties file.
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!
Martin.
