Thanks for reporting this. I’ve fixed the Branch Analysis docs. What you saw in them was the original state, and what you saw in “Gathering Lines of Code…” is the current state. Now both pages say the same thing.
Thanks Ann for being on top of my query and fixing the doc.
Can you help me with my second set of query - “what are the best practices other than branch analysis that are suggested to reduce the project lines of code in SonarQube”?
Excluding third-party libraries and any autogenerated code not being picked up by the existing efforts within the analyzers to exclude that code is a good place to start. Check out the docs on Narrowing The Focus.
In order to cleanup the server with obsolete LOC’s, I am exporting the project and taking it as backup before deleting the project. Can you confirm if this is the right approach to cleanup the lines of code from sonarqube ?
I am also trying to test import the exported project in dev environment to check if the history of the inactive project is preserved and I am getting the following error - _‘Project dump can’t be imported as installed plugins are different, See above error logs’
I checked and all plugins versions are same in both dev and prod, there is nothing in log file on the error, is there anything that I am missing here.
In documentation https://docs.sonarqube.org/display/SONAR/Project+Move under ‘How to export’ it is written that “A zip file containing all project data ex is generated in $SONAR_SOURCE_HOME/data/governance/project_dumps/export/ under the name <project_key>.zip” where as in actual, the name of the zip file is not the name of the project key, is this a bug or am I missing something ?
Uhm… it would probably be easier to just back up your database. Project export is not intended for backup; but for moving a project from one instance to another (identically configured) instance. So as soon as you upgrade the first plugin, your “backup” is no longer any good. Beyond that, if you delete a project today and want it back tomorrow, you can always re-analyze it.
As I mentioned earlier, the source and target instances must be configured identically. Make sure you have the same:
server version
edition
list of plugins
plugin versions
Perhaps. Could you share the project name and key and the zip name?
Agreeing with everything Ann said – I’d like to callout the following line from the documentation you linked.
reanalyze the project one last time to make sure it is populated with data corresponding to your current SonarQube installation
Did you do that? I could see the error you’re getting be the result from that project not having been scanned since platform/plugin updates take place, especially if the projects you’re considering removing from your instance are older, less relevant projects to you.
Also remember that you will not be able to reimport a project after making a change on your instance to the version of SonarQube or the analyzer plugins, which might call into question the usefulness of taking this approach at all.
Thanks Ann and Colin for the prompt reply, I was just hell busy last week with the cleaning up of the projects hence couldn’t respond to your post.
Thanks for letting me know the issue with plugins in exporting the project, in fact I faced that in my POC as well. Taking a backup of database might not work in my case for couple of reasons so having the exported backup of project might be useful iff the plugins are on the same version
I will share the name of the project with zip name in order to provide the example.
I believe we should not be scanning the XML and JSON files as a best practice, we should only be scanning the languages. Are there any scenarios when product wants to scan XML or JSON files ?. .
@ganncamp
Hi Ann
I would like to contribute a blog on SonarQube? I am not sure if Sonar acknowledges the blog from users?
Can you suggest the process if I have to get my blog published to sonarsouce?
Could you share the project name and key and the zip name?