No the sensors are still useful, but the the output from the sensors have already been produced from a previous run and could be reused instead of creating the same output again which is costly. Maybe I didn’t explained it good enough.
Suppose we have a source repository containing the following parts/directories:
- frontend-angular
- frontend-jsp
- backend-java
- backend-plsql
On the build server the master branch is run for the first time and the sonar analyze of the whole project is run which takes 12 min in total
- frontend-angular: 3min
- frontend-jsp: 3 min
- backend-java: 3 min
- backend-plsql: 3 min
If you had a cache, the output of every sensor are now cached (with a hash of all the source/input files as the key)
Later on a developer creates a bug fix branch to fix a problem in the backend-java and creates a pull request which creates a new build on the build server including a sonar run.
However this time the results from 3 sensors can be fetched from the cache (since no source code changes have been done there, and the output from the sensors would be the same):
- frontend-angular: FROM-CACHE
- frontend-jsp: FROM-CACHE
- backend-java: 3 min
- backend-plsql: FROM-CACHE
Developer fixes a bug during the pull request review, pushes up the changed code and a new sonar run is executed:
- frontend-angular: FROM-CACHE
- frontend-jsp: FROM-CACHE
- backend-java: 3 min
- backend-plsql: FROM-CACHE
And the pull request is merged to the master branch a new sonar run is done , and this time everything could be fetched from the cache:
- frontend-angular: FROM-CACHE
- frontend-jsp: FROM-CACHE
- backend-java: FROM-CACHE
- backend-plsql: FROM-CACHE
E.g. in this example we would have saved 10x3min of execution time by utilizing a cache. Depending on your branching strategy the savings could be even more. For example we have both specific release branches and a master branch, so a build with the same source code can happen in 3 or more branches.
Eg bugfix branch-> release v1 → release v2 → master branch.