Following an upgrade to 9.3 Enterprise from 9.2.4 Enterprise, the project homepage links for ‘New Code Smells’ and the Quality Gate Status failure conditions no longer work, instead producing: “We couldn’t find any results matching selected criteria.”.
The ‘Added Debt’ link does work, but takes time to load.
Any use of the ‘New Code’ Issues filter also fails. This is not occurring for all projects, but is consistent with the projects that it does occur with.
As per other bug reports on this site for this, clearing the cache was performed as a possible remedy. The es7 cache was removed and all projects reloaded, however the problem still remains.
Re: 1.
Yes, the projects are using the Reference Branch for the New Code Strategy.
Re 2.
This is happening on branches. Pull requests are not analysed.
Re 3.
Yes. We see the same issue on the New Code Filter.
The underlying git server is Bitbucket Server. We are not seeing it on all repos.
We have been reverted all extensions\plugins to their 9.2.4 versions but this has not resolved the issue. The issue has also been confirmed in a separate completely independent environment as well when analysing the same git repo.
i can confirm this behaviour, unfortunately this didn’t come up in our tests before.
After the update from Sonarqube Enterprise 8.9.6 to 9.3.0 this morning i had some projects
with that problem.
All use new code with main branch as reference.
The problem occured in (already existing) feature branches, " We couldn’t find any results matching selected criteria."
Workaround is to delete the branch and do a new analysis.
This analysis creates the branch and brings up old issues (i.e. 3 years old) as new issues, then set the Won’t fix status with bulk edit.
Running on Windows Server 2019 with Azure Devops as git server.
no there was no warning, also they don’t use any fancy stuff like cherry picks.
We use Microsoft Azure Devops (formerly known as Team Foundation Server) on prem
for Git management.
The scan log has only warnings about 'Invalid character encountered .. for encoding UTF-8. Please fix file content or configure the encoding to be used using property 'sonar.sourceEncoding'.
and
[WARNING] Unresolved imports/types have been detected during analysis. Enable DEBUG mode to [WARNING] Use of preview features have been detected during analysis. Enable DEBUG mode to see them.
whatever that means !?
Will do a new scan with loglevel DEBUG…
Thanks for sharing this data and a workaround, respectively.
@Will , would it be possible for you to delete any of the problematic branches on SQ and re-analyze it? If so, does the problem go away?
I believe that the issue that both of you are facing is related to this bug which was introduced in SQ 9.3 and that will be fixed in 9.4.
In a nutshell: New Code issues are accounted for correctly during the analysis for existing branches that had already been analyzed in SQ 9.2, but then the search is broken and users cannot see their details.
This is an unexpected side effect of a bug fix that was released in 9.3. This already fixed bug caused issues to appear as part of overall code (and not new code) whenever there was a “Reference Branch” being used for New Code strategy, and the branch had been rebased or had merged commits.
After this fix, every issue introduced in a new line will be considered as part of the New Code Period.
New lines are essentially lines not present in the referenced branch (for example, main).
Therefore the new issues that are popping up (even 3 years after being committed) are indeed part of the New Code Period, as they weren’t present in the referenced branch.
Hope this clarifies! In the meantime, @anon67236913’s workaround should help, and you can track the fix progress to be shipped in SQ 9.4 in Jira.
having to apply the workaround = delete the branch, rescan and create the branch again,
then bulk edit a bunch of old issues to potentially 2500 projects until 9.4 is released
and tested by us is no fun
I would prefer a version 9.3.1 with a fix for that problem ASAP.
Likewise more than 3500 branches makes this suggested workaround completely impossible. A patch release is urgently needed!.
If reference branch based New Code definition is actually working why would existing issues appear in the new branch analysis? Why would there need to be a bulk edit operation as part of this workaround?
The analysis of the branch should only show new issues in the code lines of the files that are changed by that branch, which should be 0 when the branch analysis is first created, should it not?
If reference branch based New Code definition is actually working why would existing issues appear in the new branch analysis?
Up until SQ 9.2, New Code definition was not working correctly in the scenarios in which the branches had a rebase operation or a merge commit. This was fixed with the release of SQ 9.3.
Why would there need to be a bulk edit operation as part of this workaround?
The bulk edit operation is not part of the workaround.
Those “new issues” are legitimately new issues that were not correctly identified before SQ 9.2.
The only temporary workaround (until SQ 9.4 is released) is to delete the branch and re-analyze it. This will fix the issue with the New Code filter in the Issues page.
Once SQ 9.4 is released, the New Code filter should work also for branches that haven’t been deleted and reanalyzed as part of the workaround.
Day one after the update 8.9.6 > 9.3.0
Those problems occured 3 times so far, means it’s no bushfire forcing a rollback.
Had no time for further research, but they had no fancy git operations and i’m quite sure these issues
were already fixed before - therefore the bulk edit.
But it’s impossible to dig in the history after the branches were deleted.
Will be happy if it stays like this and version 9.4 is released soon.
We are actively working on the issue, but the fix isn’t complete yet, and SonarQube 9.4 is expected in the first days of April. By the time the issue is fixed, it will be time for the release.
@anon67236913 I’m curious about the behavior you described:
This analysis creates the branch and brings up old issues (i.e. 3 years old) as new issues, then set the Won’t fix status with bulk edit.
As Belén mentioned, issues that are new compared to the reference branch are expected to be raised, even if they have been introduced in the past. They are issues that should have been raised before but were lost/overlooked because of SONAR-14929. But I’m surprised that you have such a big amount of very old issues raised in your branch. Haven’t you merged your branch in the meantime and don’t you have the same issues on your reference branch?
Thank-you for your response. It is disappointing that no patch for this Critical Bug will be issued.
We are at Day 5 of 9.3 and the count of affected projects only increases, with teams blocked because they cannot find the issues the Gate Conditions fail under.
From your JIRA, this critical bug was raised on the 14th Feb and still remains open. It was good to see some activity on the ticket yesterday. Given 9.4 has 1 critical bug and 4 major bugs still open this update may be 2-3 weeks away by the time it is fully tested.
We will rollback to our last known good of 9.2.4 and await 9.4 plus any subsequent patches until it is proven to be stable and correct - possibly 1-2 months from now. This will require reanalysing all branch checkins over the last week to bring them up to date.
9.2.4 still cannot accurately determine New Code Issues but this is the lesser of two weevils.
Day 2 after update. No further problems so far.
The three cases each brought up about 10 - non critical - issues, that were already fixed before AFAIK.
After a short consultation with the developers, i used the workaround with branch deletion, reanalyse and bulk edit with Won’t Fix so that they can continue to work.
