I have a hard time understanding how code smell analysis works?
Currently seen on a React app in Azure DevOps pipelines.
When having a Pull request going to the Master branch I see code smells reported about files that should be renamed to match the “export default something” statement in the file itself. This code smell is of course easy fixable, but I would like that code smell to be reported already when making a Pull request to our Develop branch.
To test this, I created a new branch, and added new files, and intentionally added the above mentioned code smell. I also added other code smells like imports not being used etc.
My problem is, why does the code smell about renaming the file to the same name as being default exported in the file, not being shown as a code smell on my Pull request to Develop? The other code smells I did intentionally was flagged (as expected) as code smells on my Pull request to Develop.
So in short, I get different code smells on pull requests to develop, than I get when doing a pull request to master. Can that be fixed to be the same? I would really like to fix the code smells as early as possible.
Analyzers are executed on the files configured as source code or test code, and generate issues that they find, depending on the rules configured in the quality profile per language. In pull requests, a subset of all issues will be visible: only issues on lines that changed in the pull request’s branch, relative to the base branch of the pull request.
The first thing I would look at is if the changed code is correctly visible on the Code tab of the pull request to Develop, highlighted with yellowish background. This indicates that the code was detected as changed in the pull request. The troubleshooting can continue in different direction, depending on what you see here.
It would be great to see this reproducer! Can you create in a public project to share?
The issue reporting doesn’t depend on the target branch. The same mechanism is applied whether the target branch is Master or Develop. So what you describe should not be possible. So I’m curious where the investigation will go, depending on your answers to the questions above.
Hi Janos, thank you so much for your answer, and sorry for not replying earlier, but it has been strange times with Covid19 as you know, and I moved away from investigating the sonarcloud issues I had.
I still see strange things reported in the project I am working on. This time I tried to make a full-scan of my code, by making a branch from one of the earliest commits made on the repo and then merge that branch with the code from the master branch. This will more or less make all code seem as new or it should in theory. I then made a PR of that code into a ampty sprint branch which would trygger a sonarcloud scan.
I have a file which is complex, way to complex, so I needed to do some refactoring here, and have done now, ready for release but has not yet happended. The warning from sonarcloud (before doing the refactoring) when I made a PR to our sprint branch looks like this
The same complex function is currently in our master branch, since we haven’t released the refactoring yet, so the full-scan test I did, should highlight the function as being way to complex, when doing a PR into our sprint branch right? But it didn’t. Actually the sonarloud scan only showed 3 code smells in the entire code, which is not nearly the same number as our master branch has at the moment.
When you do a PR analysis, issues that already exist in the base branch are not shown, even if the lines of code have changed. The idea is to let you focus in your PR on the new issues introduced in your feature branch, to make sure you are not making things worse. I think this is what you’re experiencing.
