Hi,
Unfortunately no, there’s a lot to do on our side because it’s a very broad subject involving multiple components, and by the way not only for Pull Request.
The documentation will be available soon on supported scenarios.
Thank you.
Mickaël
Do you know which scenarios are currently supported? We’ve been delaying our roll out of this to all of our other projects across the business due to concerns around long term scalability.
Currently, only multiple build task between begin / end step (.NET solutions only) are supported, inside a single repository.
Is it possible to run them in multiple jobs between the begin and end step, or do they have to be run in the same job?
Monorepo is a common way to manage a codebase now.
We still need a way to be able to analyze a monorepo with different code langages in different directories in a single github pull request.
We face this issue since nearly a year and the only option answered is to stop using sonar.
With the github Pull Request Status Checks API you could send different status for each analysis and group them within the SonarCloud integration:
SonarCloud / SonarCloud Code Analysis: project1
SonarCloud / SonarCloud Code Analysis: project2
…
3 Likes
Hey @mickaelcaro
I obviously don’t know what is blocking you guys in implementing this but we really need this feature. We cannot combine ~30 builds into one analysis. If one shared component is changed, all 30 builds are triggered. We are currently introducing critical issues into our codebases because sonarqube does not block us if there are multiple changed projects in one pull request. We used to use a build breaker workflow to stop bad PR’s from going through. You guys decided we should not use this workflow, fine. We stopped doing that because you demanded it (removed build breaker functionality from sonarqube plugin). But the new suggested workflow has not worked correctly as a replacement because it only sends one quality gate back to azure devops.
From the outside the issue seems very clear and the solution seems easy. The build pushes the analysis to sonarqube, sonarqube generates a report and quality gate. This all works.
Now sonarqube sends the quality gate back to azure devops as a pull request check/decoration. Some logic on sonarqube decides that only the last generated quality gate associated with a PR should be sent back.
The correct solution would be of course, for every sonarqube project analysis associated with a pull request, send back the last quality gate.
You say this requires deep modifications in the engine. I’m not seeing why that is the case, but then again I don’t know sonarqube internals.
You speak of ‘analyzing a same repository by multiple pipelines’, but this to me does not seem relevant. We are not analyzing a same repository with multiple pipelines. We are analyzing specific c# projects that have associated specific builds for each project AND associated specific sonarqube projects for every single c# project. The biggest issue I’m seeing that is blocking us is that sonarqube sends the pull request check with the same ID every time, which overwrites already received pull request checks. If sonarqube would send unique checks for every quality gate/project we would already be unblocked. If that means pull request decoration or some other parts don’t yet work I am happy to accept that, as long as the check is there and goes red for a red quality gate.
Is the use case clear with sonarsource? To me it seems like there is still some confusion as to what we want to achieve, because without any knowledge of sonarqube internals it seems to me like there are some quick fixes that can be made that would not fix everything completely but that would unblock us asap.
3 Likes
Thanks for your input @Rouke.Broersma.IS. We have been in exactly the same position for a year now. Still waiting for a solution, whilst the codebase silently deteriorates.
Also would you be able to share the JIRA ticket for this issue? The only one I can find is this one: https://jira.sonarsource.com/browse/SONAR-11870
And the case described there is NOT what this problem is about. That’s why I’m asking if the actual use case we’re having issues with is clear to sonarsource. This ticket is talking about one pipeline that triggers multiple analysis. We are talking about one pull request that triggers multiple pipelines that each trigger one analysis.
To be honest though, frankly any way of running builds in a more efficient way than all in a single job would be much appreciated.
Getting PRs closed is somewhat painful at the moment.
1 Like
Another vote for this issue
2 Likes
@mickaelcaro @Fabrice_Bellingard Is there any movement on this?
We are severely limited by the SonarCloud analysis step when it comes to our PRs. We can now run a full master build, test and deployment in around 20 minutes, whereas our stripped back Pull Request builds take about an hour and ten minutes. Try as I might, I can’t fathom a way of making these any more efficient than they are.
This makes our development process extremely painful to the point where I am receiving backlash from the rest of the development team about build times. It is now reaching the point where we need to hear some sort of solid plan on what is going to be done to improve this or we will need to re-assess the tooling that we are using here.
Hi, any update on this request to allow for a PR to be decorated by multiple builds? This is still a significant issue for us as well.
1 Like
Hi,
Not yet unfortunately, the specification of that feature is still ongoing.
Mickaël
+1 on this request, my team is in the same boat. We have one Azure DevOps git repo running multiple pipelines with pathfilters configured with their own sonarcloud analys project.
When we create one PR that change multiple directories, multiple pipelines are triggered and PR decorations are at first populated but after last one finishes all gets deleted except the first who arrived.
What we came up with is to use multiple user PAT’s for the different sonarcloud analyses, this maintained our comments when all builds were completed.
Worth mentioning is that we only have one analys per agent, but there can be multiple build agents in one pipeline.
2 Likes
I like you’re solution regarding the different PATs. This is something we might implement whilst we wait…
Out of curiosity, how do you find the multiple users works with code coverage statistics? It’s something we might implement too.
Short answer: As long as code covrage file(s) is present before running ‘Run Code Analysis’ step you´re all good for codecovrage.
Long answer:
Can’t run splitted codecovrage/unittests results with sonarcloud (limitation in analys engine). What i did was split it over multiple agents our current most ‘complex’ pipeline is as follows.
MSBuild Test (2 pipelines/agents)
Npm Test (2 pipelines/agents)
MSBuild Main build + sonarcloud analys
From all test pipelines we upload the analys files (*.trx and junit.xml) to the same Azure artifact, then in the main build pipeline I have a powershell csript to check and validate that artifact has been uploaded before download / ‘Run Code Analysis’-step.
I splitted Test builds as we dont need analys step when just running test, also doing a incremental build.
This resulted from a 19 min buildtime using 1 agent down to 5 minutes. Also you can run custom conditions so you dont run sonarcloud analys on manual triggers etc.
Hi
Any updates on this?
1 Like
Also interested in this feature; as we have three projects in a single repo, and run analysis via CI on each of the projects - yet there is just one decorator on the PR.
1 Like