We’re using GitLab for CMake/C++ builds, and for various reasons (e.g. cross compilation to several different targets) every build is done on several machines in parallel. This, however, causes intermittent failure when uploading to sonarcloud because there are several interleaved runs of sonar-scanner using compile_commands.json, finishing their uploads for the same commit at indeterminate times. Errors look like this:
Validation of project failed:
o Date of analysis cannot be older than the date of the last known analysis on this project. Value: "2023-08-08T13:56:05+0000". Latest analysis: "2023-08-08T13:56:10+0000". It's only possible to rebuild the past in a chronological order.
At least I am guessing that interleaved uploads are the source of the problem.
Is there any way around this other than to serialize all our builds (that would take prohibitively long)?
I imagine that we could do the scans when building, and then have a separate step, after all builds have finished, to upload the scan results, but I have not seen support for anything such in the docs.
Ultimately – analyzing multiple code variants on the same branch of a SonarCloud project is either going to lead to this issue, or general incoherency of analysis results (you’ll only ever see the latest analysis).
You can pass a different sonar.branch.name for each different variant (better than separate proejcts which will jack up your license utilization)
Coming back to this. The technique with sonar.branch.name and sonar.branch.target works, a bit ugly, but it works, Except for Merge Requests. I have not been successful when playing with sonar.pullrequest.branch and/or sonran.pullrequest.base. Is there some other similar work around that I’m missing?
@Geoffray do we have any recommendations for users trying to do PR analysis with multiple build targets, without the implementation of code variants like we have on SonarQube?
We do not have built-in support for the use case you describe (yet).
The problem also exists on SonarQube but this feature recently vastly improved the situation; another one is under consideration to help with the case of concurrent analyses.
We have multiple workarounds, none of them being perfect. I will list them all for later reference:
One branch per variant: the explosion of the number of branches (cross products), no way to handle common issues, PR analysis logic is not well-suited
One project per variant: multiplies the number of LOCs; most of the previous drawbacks
One monorepo for all variants: like the previous one but fixes PR feature (requires Enterprise Edition for SonarQube and it is available on SonarCloud)
Analyze only 1 variant (by far the most used): do not analyze most variant specifics
Analyze only variant-independent code: difficult or impossible to do, miss all variant-dependent specifics.
You discussed option 1 with @Colin .
In your case, option 3 may be better at the expense of an increased number of projects/Lines Of Code.
On a final touch, as Colin was mentioning, SonarCloud versions of the features I was mentioning for SonarQube are both under consideration.