Hi,
I have sonarqube 8.2.0.32929 developer edition, with bitbucket ALM.
Right now it is possible to run multiple project analysis using gradle task like, “gradle :subproject:proj1:sonarqube :subproject:proj2:sonarqube”
This command runs analysis on sonarqube proj1 and proj2.
But When I do pull request analysis, only comments from last proj (in this case proj2) are displayed in pull request.
Is it possible to display all possible issues under this pull request.
I even tried to get all open issues in the PR manually via API but I had no success.
So we have multiple sub projects with in a big bitbucket repo, and we treat each sub project as a separate project in sonarqube.
so in a pull request it might happen that multiple sub projects are changed.
With the gradle command ( mentioned in prev comment ) , all sub projects are analysed and I can see branches in sonarqube server, but the comments on pull request from sonarqube extension are only displayed for one project and not the rest.
so, I was wondering if one of the option is a possibility,
Allow extension to show all comments from multiple projects.
Get the open issues in a pull request across multiple SQ project via API. ( and then I can comment on pull request via bitbucket api )
This is par for the course. We’ve got monorepo support in our grand vision for the year, but we haven’t started working on it yet. And unfortunately, I can’t think of a workaround that wouldn’t explode your billed LOC.
There are web services to supply this data. The best way to figure out what they are is to look at it in the UI and sniff the network traffic via developer tools.
We have a similar issue: A multi-language project.
Java which is build with ant and analyzed
C++ which is build with msbuild and analyzed
The code interacts via JNI.
In Azure DevOps we build the two parts in parallel jobs (i.e. separate build servers).
Only one QualityGate is displayed and issues commented in the PR. On SonarQube server both parts are available.
I assume that the slower build deletes the report of the faster one.
Addition: In the summary tab of the build, both analyses are shown. Only in the PR there is only one reported.
Addition 2: Seems to be discussed and given to your dev team in this discussion
So you know, handling this nicely might make it into the LTS, although time/space for that gets increasingly tight.
At the same time, I want to point out that this would work (yes, I understand you may have external constraints that make this solution unavailable to you)
Check out all
Run Java/Ant build
Run C++ build with build-wrapper
Analyze all (-Dsonar.sources=path/to/java,path/to/C++ -Dsonar.cfamily.build-wrapper-output=build_wrapper_output_directory ...)