Hi! I’m using SonarQube Enterprise 9.9 LTS (Docker), used primarily to support a large monorepo that also happens to host a monolithic project comprised of many individual apps. This is a conceptual question, and I think I know the answer, but want to be sure:
Can SonarQube support PRB decoration and Github app checks in a configuration where a single PRB might include a change set that spans multiple SonarQube projects? I recognize that this question probably makes you think that something is fishy on my end - and, that wouldn’t be an incorrect feeling To summarize the rationale for the current configuration: different teams work on different parts of our monolith, so we model those parts as distinct SQ projects to easily aggregate isolated metrics at a per-project level.
One way that we might be able to proceed is to attribute all PRB scans to the single top-level Maven project. This would mean we don’t have the opportunity for isolated per-app policy configuration in a PRB context, and would also mean we need to maintain an additional top-level project on the SonarQube side that has up to date scans of the entire repo, IN ADDITION to the per-app projects and scans we’re already maintaining.
What you’re looking for is monorepo support, which does exactly what you describe:
In a mono repository setup, multiple SonarQube projects, each corresponding to a separate project within the mono repository, are all bound to the same [DevOps platform] repository. You’ll need to set up each SonarQube project that’s part of a mono repository to report your quality gate status.
Unfortunately, we don’t seem to have generic docs describing the general scheme of this; they’re all DevOps platform-specific. You don’t mention which platform you’re using, so here’s ADO and GH docs links, chosen somewhat at random. (In case I’ve missed the mark, the docs search is pretty good )
For the benefit of other readers, I should note that monorepo support starts in Enterprise Edition($$) (which, yes, you’ve already said you’re running. ).
Thanks for the reply I’m aware of the monorepo feature, however I think this feature assumes that the changed files in a given PR against the monorepo will not span multiple monorepo-mode SonarQube projects. In our case, the software in the monorepo is also monolithic - there are build-time dependencies between apps in this monorepo. It’s not uncommon that PRs have a change set that spans multiple apps - sometimes a change would affect ALL apps in the monorepo (eg top-level pom.xml). In this scenario, how would something like PRB decoration work? Wouldn’t the SonarQube project for each changed app need to supply decoration? Is that supported?
For quality gate checks, if there are multiple projects reporting on a given PR, is it correct that the PR is green if all of the reporting projects report green, and the PR is red if any of the reporting projects are red?
Related to scalability of monorepo-style projects in a PR context: can you provide any examples or descriptions of what it looks like when multiple projects report on the same PR? In particular, is there any affordance for combining, summarizing, or conditionally suppressing the reports, while still executing the analysis for all projects touched in the PR? How many projects can participate before things become unwieldy, impractical, annoying, or otherwise ill-advised? If you’re not sure, I’ll ask in a different way: in your experience, what’s the largest useful configuration you’re aware of measured by the number of monorepo-mode apps decorating a given PR?
For your second question, I honestly don’t have any experience with monorepos that large / spread out (with say, more than a dozen SonarQube projects), so anything I say would just be a guess.
I think you’ll have a lot of theoretical questions until you try it out yourself! Since you already have an EE of SonarQube, it’s at your fingertips.
To summarize the rationale for the current configuration: different teams work on different parts of our monolith, so we model those parts as distinct SQ projects to easily aggregate isolated metrics at a per-project level.
)
).