Template for a good bug report, formatted with Markdown:
versions used (SonarQube, Scanner, Plugin, and any relevant extension)
sonarqube version 188.8.131.5208
SonarScanner for MSBuild（sonar-scanner-msbuild-184.108.40.2062-net46）
Plugin( sonar C# 7.9.1 (build 7622) installed)
error observed (wrap logs/code around triple quote ``` for proper formatting)
When nobody edit the source code, sonarqube will auto close and open issue
1.I try to google “issue changelog sonarqube”, but I can’t find the document about how to find the issue change log in sonarqube. Could you tell me how to check this?
2.About “which issues are considered new”, I think it’s not possible caused by this since nobody modify the source code, we just build the project in Jenkins and send it to sonarqube by scanner.
3.Another new situation I found is:
We build multi projects in one Jenkins project with pipeline, but only one project has the problem. The others will not auto close and reopen issues. I am not sure if we configured that project correctly. I will check the scripts with our configuration engineer later.
After compare with the other project’s activity in sonarqube, we found the project which has problem with weird behavior.
It will stop using sonar way(python) , stop using sonar way(xml).
What did this mean? The source code of our project is C# .
My colleague is using pipeline to build several projects.
Project B has a reference of Project A.
Project C also has a reference of Project A.
When Project B rebuild, it output dlls to a common folder, and send a request to sonarqube.
However when Project C rebuild, it output the dlls to the same common folder.
We guess the problem might caused by the second rebuild, it will overwrite the first rebuild. We will try to split the output target folder between different projects to see if it can solve the problem.
If the same issue was closed and then reopened, it will show up in the issue changelog. If however, the issue matching algorithm wasn’t able to make the connection between the old one and the new one, your “new” issue will only have creation in it. That’s why I referred you to the docs about what issues are new.
But noow, looking at the activity log from your most recent followup I see that your use of the relevant profile fluctuates from analysis to analysis. It looks like your analyses alternately do and then don’t include your Python code. If all your analyses included Python, then you’d see multiple events on each analysis:
Stop using ‘Sonar way’ (Python)
Start using ‘Other profile’ (Python)
The only time you use no profile at all for a language is when that language isn’t found in the project. So, your investigation needs to back up to why Python
The issue was auto closed then re-opened again and again.
I re-check the activity of the sonarqube project, I found the project the profile was in a weird loop
1.start using sonar way in first build and scan
2.stop using sonar way in second build and scan
3.loop 1 and 2
I find there are some *.py files in our project, and these files are referenced from third party.
How every these files will not be compiled by msbuild, they will only be copied to the bin folder by *.bat in post-build event of visual studio project.
I do not know how sonarqube works with msbuild scanner, what kind of files will be scanned?
We have a .bat file to copy *.py files as following
xcopy “%projectDir%\fckeditor” “%TargetDir%\fckeditor” /e /y
I am not sure if the post-build event will finish the copy action before msbuild scanner starts to work.
I could try to move the operation from post-build event to pre-build event.
However, the problem still exists, why the python sonar way would affect the result of C#? Since they are two different quality profiles.
As discussed in the StackOverflow answer you referenced earlier in your thread, you need to investigate your CI to see why you’re having these fluctuations every other analysis.
From your issue change log screenshot, my best guess is that analysis of a branch where the issue is fixed is interleaving with analysis of a branch where it’s not. This interleaving of branches or analysis configurations or methods could also explain why XML, and Python analysis turns off and on.