versions used: SonarQube 8.4.1.35646 Enterprise, storage is SQL Server 2016 Standard
error observed: hotspots I’ve marked off as safe keep reappearing with no evidence they were ever marked off
This is a strange one, and appears to have started once we upgraded to 8.4 from 8.3 - and set up pull request decoration (those were both done about the same time). It is only happening to one project. I noticed on Monday that one project had a high level of security hotspots. I looked at them, and was pretty sure they were ones I had marked off previously. They all had old creation dates. I went through and marked them all safe again. Yesterday morning, same thing. This morning, they are back again. None of them have anything in the Activity section showing they had ever been marked safe.
They are not reappearing during the day as a result of any of the CI builds. I ran our scheduled overnight build again this morning, and the couple I marked off before doing that didn’t reappear. So, my assumption is some SonarQube maintenance routine is doing this.
There are over 200 I am having to mark off, which is quite tedious since you can’t select multiple at one time and change their status. Any help would be appreciated.
Edit:
It looks like this started happening on 8/11, per logging we have that queries the API and captures the number of open bugs, hotspots, etc. per project. We updated to 8.4 on August 4, and started adding pull request decoration on 8/10.
I’d like to confirm that you are clearing Hotspots on the same branch that you are scanning. Ex, you clear them on a PR branch and then scan the main branch in CI.
If you are observing this on the same branch, can you provide the commands you used when you performed that caused the Hotspots to reopen? Also, the scans you performed in CI when they did not reappear?
I only ever clear them off of the master branch. I did notice yesterday that they appeared and disappeared quite a bit as various PR scans ran. There didn’t seem to be a consistent pattern to it, though. So far today there has been one general scan (scheduled) and three PR scans and the ones I have previously marked off have remained on this list.
The Projects page shows the results from the master branch, correct? That’s where I notice the numbers changing, then clicking into the project I see the same result.
I’d like to clarify your process here, please correct if I am wrong:
“master” branch scanned, there are new Hotspots
Mark Hotspots as “safe” in “master” branch
Create a “pr” branch
Run a scan on “pr” branch with all pull request parameters set
Run a second scan on “master” and Hotspots unexpectedly reopen
In the above, I’m assuming no merging is happening on master between steps 1 and 5. Hotspots should not reopen on master if they were marked safe there and the fact that PR scans are running on other branches is a non-factor.
I suspect that your scans may have inconsistencies between what is checked out on the file system and what branch/PR parameters are being applied. I suggest you review these and make sure everything is consistent.
If this does not help, attaching scan logs (preferably with -X debug option active) and the git commands your CI is using would be useful in investigating further.
Master branch is scanned on an overnight, scheduled scan
In the morning, I go through and mark anything as safe that is warranted. Lately, I’ve been having to mark off things that were previously marked off.
During the day, pull request scans are triggered from Azure DevOps as they are created.
Those pull requests get merged to master (if they get approved) - not necessarily before the pull request scan has completed. We have them as optional requirements on the pull request, because some of those DevOps pipelines (build + scan + dependency check) take 40 minutes or so.
Watching it yesterday, the hotspots were sometimes there and sometimes not after a pr scan. I don’t know how the day ended.
This morning, they were all back.
Your questions to raise a point to me - for the ones where I’m seeing them come back, are they for pull requests that were merged to master (and if so, merged while it was running, or after), or ones that were not? I don’t know the answer to that.
Note: the things I keep having the mark off, these were things I marked off months ago. They had been off the report for a long time. They started re-appearing after we added PR scans triggered by Azure DevOps.
The other odd thing about this, is they show up with the original creation date - not a new date as if it was recreated. And, they have no activity history listed, other than creation.
I have some more information. It looks like it’s happening on the CI build triggered as a result of merging a PR into master.
Also, looking at the database, I believe it really is recreating them. I grabbed the kee for a hotspot I know I previously marked off, then queried the issues table. I then queried for issues with the same component_uuid, project_uuid, issue_type and rule_uuid. There are 12 of them so far. The only difference between the open and closed ones (besides the obvious ones like kee, created_at, issue_close_date, etc.) are:
line = 30 (all others are NULL)
status = ‘TO_REVIEW’ (all others are CLOSED)
resolution = NULL (all others are FIXED)
I then marked it safe, and it changed to status = ‘REVIEWED’, resolution = ‘SAFE’. I assume after another scan runs, it’ll get closed.
Some more information. There is now a 13th instance of this hotspot. The previous one flipped from reviewed/safe to closed/fixed (and line set to null) last night during a scan triggered by a PR merge. Specifically:
The DevOps build started at 11:17 PM
The SonarQube code analysis started at about 11:34 PM
The issue’s issue_close_date was set to 11:36 PM
Code analysis finished about 11:38 PM and the Publish Quality Gate Result started
The issue’s updated_at was set to 11:44 PM
The Publish Quality Gate Result finished at 11:44 PM
The scheduled scan started at 3:30 AM
A new issue was created at 4:01 AM, at the end of the Publish Quality Gate Result
What is causing issues to continue to be recreated, after I mark them safe? I’ve marked this one safe, again, before any other build runs since the scheduled one on the master branch. Note: we are seeing this in other scans now, too. It was just more obvious in this one because of the number of hotspots that are safe as written.
The information you are providing is insufficient to determine what is the issue. As mentioned earlier, if you post the scan command line, git commands and logs used in your builds, we can investigate further.
For which? When it gets marked closed or when it gets recreated? These are DevOps tasks, so the command line logged there looks like this:
Prepare:
d:\AgentData\Agent-Azure02_tasks\SonarQubePrepare_15b84ca1-b62f-4a2a-a403-89b77a063157\4.11.0\classic-sonar-scanner-msbuild\SonarScanner.MSBuild.exe begin /k:OAS.WebApi
Run:
d:\AgentData\Agent-Azure02_tasks\SonarQubePrepare_15b84ca1-b62f-4a2a-a403-89b77a063157\4.11.0\classic-sonar-scanner-msbuild\SonarScanner.MSBuild.exe end
For the scan where they get recreated (target branch) would be most helpful, but both are preferable. Please make sure DEBUG (/d:sonar.verbose=true) is set in your begin step. I am also interested in the git commands that are run around these so that I can recreate your scenario if needed.
,