We discovered the following behaviour in a failed/crashed C++ code analysis:
Due to missing space on the drive the compilation stops but the build-wrapper analysis was executed anyways.
Because of the stopped build the analysis was only executed for parts of our code base so a lot of issues were gone / closed.
After the next correct analysis some of the the issues wrongly closed occur as new issues in Sonarcloud, but only the issues which were not tagged and not assigned. Issues that were tagged before the failed analysis are still there and not recognized as new issues.
Why is there a difference between tagged and not-tagged issues? Is there a possibility to only execute the analysis if the build was done correctly?
Hello @stefansta,
I can answer for the CFamily analyzer
Is there a possibility to only execute the analysis if the build was done correctly?
build-wrapper will return the same exit code as the instrumented build command. If the build command returns non-0 on failure, build-wrapper will do the same, so you can catch there was a failure and stop there.
After the next correct analysis some of the the issues wrongly closed occur as new issues in Sonarcloud, but only the issues which were not tagged and not assigned. Issues that were tagged before the failed analysis are still there and not recognized as new issues.
Both matching to previous issues and backdating follow heuristics, but I could only speculate here. I leave it for someone else with deeper knowledge in this area. I wonder if the untagged, unassigned issues show as reopened or really as completely different ones, though.