We are implementing clean-as-you-code with sonar enterprise on a system with many existing sonar issues. We are using pull-request analysis to identify new issues as part of the process of merging of changes to master or release branch. However sometimes there are issues that are two complex or risky to solve in the context of standard development (such as resolving a “Monster Class”) and should be planned rather than fixed ad-hoc as part of a random development.
We are putting in place a process that when a developer hits one of these blocking issues we can treat it as follows.
Close the issue on the parent branch (master or release branch) as “won’t fix” so it does not block other developer merges.
Tag the issue with ‘fix-later’ on the parent branch so we can track all escaped issues.
Add a Story to track the issue in our agile development process for future planning.
My understanding is that closing/tagging an existing parent branch issue in the pull-request scan analysis won’t be promoted to the master branch in sonar so this should be avoided (unnecessary work). To minimize developer effort the issue should be closed on the parent branch, then when the pull-request analysis is rerun it will report a clean result and the developer can proceed to merge their changes to the parent branch.
Are there any additional recommendations to the process defined above?
Is there a way to go directly from an issue reported in a pull-request scan to the same issue in the parent branch? The best way I have found is to do the following which is cumbersome.
In a new browser window open up the parent branch issues list (so you can compare between the pull-request issue to close and its representation on the parent branch).
Filter the results by the source file reported in the pull-request analysis.
Search the resulting list for the pull-request issue or add additional filters to reduce the search further (such as filter by the ‘rule’ from the pull-request analysis).
We would like to make handling of the sonar analysis escapes efficient as possible so being able to quickly identify the issue on master, close it, and tag it is beneficial since there are a lot of legacy issues in the code base.
This is a problem in clean as you code if you need to make a small change to a “Monster Class” for example. The change to the “Monster Class” will trigger the rule in the pull-request scan and report this as an issue to be fixed, even though the small change was simply making the existing issue worse (not actually creating the issue). The merge process we are implementing is requiring a clean pull-request sonar scan and fixing the “Monster Class” can be either too complex or risky to merge along with the developer’s original changes.
To address this we are putting in place a process where we will mark the issue as “won’t fix” and tagging it ‘fix-later’. This will allow the pull-request analysis scan to complete successfully (allow merge to proceed based on our merge criteria) and marking the class for attention in the future when the changes can be designed and planned.
From testing and reading the sonar documentation, closing issues as “Won’t fix” in the pull-request will not merge into the parent branch if they already exist there. Closing the issue on the parent branch as “won’t fix” and tagging with “fix-later” is important because…
This issue is now known to impact current development and other developers may hit it again, so there is no reason for future pull-requests to report this issue again. Marking it as “won’t fix” in the parent branch will quiet the issue from future pull-requests scans that impact the issue again in a different way (i.e. additional changes to the “Monster Class”).
Making these changes on master (especially the ‘fix-later’ tag) helps us track which items are actively impacting development so we can plan correcting them. If the tags exist only on the pull-request branch they are much harder to track.
The goal of our version of “clean as you code” is to…
Prevent the entry of new sonar issues into the code base.
Identify old issues impacting current development and have a strategy for fixing those issues if they are too complex or risky to fix immediately.
Implement a procedure that accomplished goals #1 and #2 above that has minimal impact on development.
One part of the process I outlined that is more intensive than desired is correlating pull-request issues to the existing issues on a parent branch so we can close and tag them. The best procedure I know of to identify a parent branch issue is to open a new browser tab/window and use one or more the filters in the sonar UI until you can identify the issue to close/tag. Is there any short cut to go from a pull-request issue to the same issue in the parent branch?
I understand now. For threshold rules, changing the number (even reducing it IIRC ) will re-trigger the issue.
Ah! Okay.
Maybe? This is not something we’ve explicitly designed for, but maybe it’s possible to cobble together a workflow. What version are you in? In the latest versions, there’s an ‘Open in IDE’ button on each issue. That opens the issue in SonarLint. Now, SonarLint does have some branch awareness, which might be troublesome here, but from SonarLint, you can mark the issue Won’t Fix (which is renamed ‘Accept’ by SQ10.6), and if you’re in Connected Mode, that will update the server.
This is the version reported on the bottom of the UI. I do see the “Open in IDE” button.
Enterprise Edition
Version 10.3 (build 82913)
We do use Idea and sonar lint and I have configured the sonar enterprise server in my Idea. I have some performance issues with the sonar lint plugin from time to time with synchronizing with the server which can take a long time. I am in the US and the Sonar Server is is Germany which may contribute to these issues. If I can get synchronized I can explore this interface to see if it is easier to navigate.
I do see a button in 10.3 for this, but I am not sure it is working and I do have performance issues with my sonar lint. I will see how navigating issues works from sonar lint if my IDE completes synchronization with sonar server. There are a lot of issues in our project which can also contribute to performance I think.
I also noticed a snag in the process. Today I attempted to tag an issue with ‘fix-later’ by clicking the ‘+’ next to the tag list but my changes were not being applied. However if I select the issue and do a bulk change to add the ‘fix-later’ tag that works.
Are there known issues with adding tags to issues? I couldn’t find anything on this. I believe I used the ‘+’ to add a tag yesterday, but it is not working today.
Tagging issues with ‘fix-later’ is a step in the process I outlined earlier.
I’m not aware of anything reported with adding tags in 10.3. And I’m not able to reproduce this in 10.6.
Are you sure they’re not added? Because what I see in 10.6 is that only one tag is shown, no matter how many there are or how much room there is to display them. And that has been reported internally. By me. Several months ago. I’ve just nudged that report. Maybe it’ll get on the list for 10.7.
I am sure it was not accepted because after attempting to add the tag I clicked the ‘+’ again and ‘fix-later’ was not present or selected.
Trying to add the new tag by clicking the ‘+’ opens this dialog.
Clicking the checkbox next to the ‘fix-later’ listed as a choice closes the dialog and does nothing. If I click the ‘+’ again I see this dialog and if no filtering is entered I can see what has been selected. In cases where there are multiple tags I do see multiple checkboxes selected.
If I do the same process using bulk update, I get the same dialog but the tag is applied.
If I open the dialog after selecting a tag I can see the tag in the bulk dialog and applying the bulk changes updates the issue making the tag visible in the UI for the selected issue.
Not a critical issue since there is a work around to use bulk update, but it does make communication of this process more difficult since users will need to be instructed on how to work around this problem if it happens.
) will re-trigger the issue.
