Interesting question that you have here, and upfront I’ll acknowledge that we don’t have an optimal solution with SonarQube.
You cannot analyze all builds within a single project. Even if there would be workarounds, that would probably be an ugly hack, not future proof for sure.
As a first step, you can analyze each binary as a separate project. This is however not optimal because you’ll consume several projects (and LoCs) for what in actually a single source code project.
The next improvement is to analyze each build as a different branch in SonarQube. You still keep everything in a single project (which is good) but it has its limits too:
If you mix branches that are different builds of the same code (“build branches”), and branches that actually corresponds to code changes (feature branches, hotfix branches, etc…) you’ll get an explosion of branches, a bit difficult to manage properly in SonarQube
It’s still impossible to analyze the PR for different “build branches” and get a consolidated PR decoration.
We’re aware of this limitation. Similar problems may occur with monorepos (a PR can be decorated only by one pipeline). We have done something about that on SonarCloud (see MMF-2001) and we can be hopeful that something similar will land in SonarQube some day, although i cannot tell you when.