SonarJS appears to be rescanning entire file if there is no new code/only deleted code

Template for a good bug report, formatted with Markdown:
SonarQube server, developer edition, 7.9.1.27448
SonarJS 6.1 (build 11503) installed

Deleting an unused function from a .js file (with no new code being added/changed) appears to trigger an entire rescan of the file. Thus failing quality gates and similar for old issues that haven’t been addressed yet.

The logs show:

WARN: File '/var/lib/jenkins/workspace/_ITSVC-4330-this-ticket-is-a-lie/includes/form_functions.php' was detected as changed but without having changed lines WARN: File '/var/lib/jenkins/workspace/_ITSVC-4330-this-ticket-is-a-lie/portal/js/global.js' was detected as changed but without having changed lines

The php file scans as expected (no new errors found, etc) however the .js file finds 1 new bug, 119 new code smells, etc.

to reproduce:

  • Do an initial scan of a legacy project that includes .js code. Preferably, legacy code that would fail current/modern quality gates… But it will “pass” because it’s the initial scan. (in our case, it was php and js)
  • After that scan, create a new branch. delete some functions or other code from the .js, do not make any other changes (don’t fix typos, don’t add comments, nothing else new/changed)
  • Run a new “branch aware” scan.

You’ll find the above warnings in the log. the PHP files will show as epxected (no new errors/vulnerabilities/smells) but the .js file will show all of the issues as “new”

Hi,

Are all the lines in that JS file highlighted as “new” (yellow background)?
Is it a short living branch?

Any chance we could get the scanner logs with debug enabled?

It looks to me that git is not finding the merge base commit for whatever reason. Strange thing is that in v7.9.1 that doesn’t explain by itself why issues would appear as new in the short lived branch.

Duarte,

Thanks for the response.

My team has been trying to debug this issue, and determine workarounds so, I’ll need to create a test project, and test branch to duplicate the issues again in a pristine environment. As such, I can’t produce the debug logs until tomorrow, and I can’t answer if the file is being highlighted as new.

That said, you mentioned that it seems like git can;t find the merge base. I can tell you that this team did specifically create the branch via the jira/bitbucket UI, not natively in git. so now I’m wondering if maybe that factors in (though, I have tried to duplicate the issue via that method, but still only see the issue when I delete lines from the .js file.)

I’ll get the requested info for you tomorrow or possibly monday. Thanks again.

1 Like