I’m wondering if it’s possible to view all issues of a PR branch - not only the new ones?
We are using SonarCloud with Azure DevOps since recently. We are fixing bugs / code smells that SonarCloud detected. We are doing this in PRs with short-lived branches. The quality gate only shows new issues and code smells. But of course when fixing bugs, I’m interested if the bug is really fixed in the PR.
Is it possible to view all issues in a branch just like for the master branch? Or alternatively, is there any way to see what bugs / code smells are fixed in a PR (it only shows new ones, not fixed ones)?
On PR we only shows issues introduced by the code changed/added in the PR.
We currently don’t show the issues fixed by the code of the PR. We may add this at some point in time but we don’t have anything plan in short term.
When you said all issues, which issues would you except to see in a PR other than the new one?
Thanks for your reply. Seeing fixed issues in the branch view would be great. Would make it easier to verify that they were really fixed before merging a PR.
In the branch view, it would be great to have the option to view all issues of the whole codebase - but based on the code of the (short-lived) branch. So in addition to only seeing the delta of your PR you could also see the general impact of the PR. E.g. if you have a master branch with 10 issues and a PR that fixes 2 of them, the view-all-issues-of-this-branch view would show you the remaining 8 issues in the codebase.
Thanks for clarifying. Our product focus on the fix the leak method (i.e focus on fixing the new/changed code). So we probably won’t add this view-all-issues-of-this-branch view.
I’ve created a report on the master and created a branch with most of master issues fixed. I wanted to show the team, look, I’ve fixed all these issues in the branch but sonar just shows 0 :(. It would be nice if there is a way of showing all the issues and maybe compare them to the master branch (or any other branch).
The only way I can demonstrate the fixed issues is by sending the branch report into sonar master report so the charts show how issues were reduced.
I understand the leak method, but if you don’t show the improvements in a branch it seems like a branch doesn’t add any value to the master.
Totally 100% agree here @fboucquez. Showcasing Sonar to my team as well. Seems like a huge oversight and a lack of important feature (and a simple feature) that would be of tremendous help in fully adopting SonarCloud, as I have a huge repository with many branches (we use staging for development, so master stays stable) and we simply cannot afford to make merges into master just to see if issues have been fixed. Very strange
I would also be very interested at the “view-all-issues-of-this-branch” feature. I think it would be very useful to me.
Actually " fix the leak method" approach is perfect if master branch is issue-free (or with only “false positive”), but what’s about an old project that need to be recovered?
There are also other use cases when seeing all issues on a feature branch is necessary. Rules might be added to your quality profile or existing rules can be changed. This can happen because you freely choose to do so or it can happen with an update of the static code analysis. You will then have new issues on your master branch, but you will not see if you fixed them on your feature branches before merging.
I am currently confronted with this problem. That is why viewing all issues on a short-lived branch would also be necessary for me.
It would be so nice to see that the code changes that I made will really resolve some issues. It would be unfortunate to merge the PR, and then after the merge see that some of the hoped-for resolved issues are not actually resolved.
If a PR actually improves the code-base, it seems logical that the metrics of the improvement should be visible.
Wow-- I am also disappointed to hear that this is not the case. Fix the leak is great if your master is perfect, but right now I am rolling SonarQube out across our development teams, which means we are doing initial cleanup and our masters are not quite perfect. I was hoping to be able to showcase a huge win (a simple, easy to fix problem has been fixed in many places across one set of code) to a development team later today, and telling them that they can’t tell what has been fixed until they merge to master is disappointing for both infosec and development teams.
Unfortunately we do not have an update on this feature yet. You can start following & upvoting this card on our public roadmap: Fixed issues in PRs - SonarCloud | Product Roadmap . We are going to post an update as soon as there are any news.
I wonder, why it could be so hard to implement that feature? Is there a workaround? How do others introduce SonarQube to an existing code base (and try to fix all reported issues)?
Please Sonar! You already have this information, so please make it available to us. ‘Fix the leak’ is great, but there is no reason why you should not also give us the full information about the branch.
We looked into pulling SonarQube issues into GitLab’s built in CodeQuality reports with a custom CI job and realized we cannot do that until the SonarQube API supports this.
Currently, the only way to see information in GitLab is from a single comment on the MR that only displays new issues for that specific MR. There is no way to look at the history or complete set of issues without going to the SonarQube web UI.
Unfortunately just listing “fixed” as well as “new” issues is still insufficient for our use case of integration with GitLab CodeQuality reports. We would just need a list of all the issues.
This also does nothing to help those who set up SonarQube/SonarSource after projects have been around for a while and have imperfect main branches. I really don’t see any reason why it would be undesirable to know all of the issues for a branch? In fact, to even be able to list the “fixed” issues you would have to know about all of the issues anyways right? Same thing for even just the “new” issues. You can’t inform about those unless you already know about all the issues. Why not just expose that to end users in the first place?