TL;DR: Basically what I am looking for is a way to get a list of all sonar rules that have 0 issues raised. I could then move all of those to blockers and protect myself from someone adding that issue in the future.
My company is using sonar and static analysis to help guide refactoring and development of a sizable legacy codebase (~750K LOC). We have had a lot of success by lowering the severity of most rules and then choosing a smaller set of rules to promote up to blocker or critical as we find real issues in the code. This has kept the number of issues we are trying to address at a time manageable so we can actually feel like we are making progress and not drown in the noise of legacy issues.
In particular when we have been bitten by a field or QA issue that sonar could have detected we turn that issue up to a BLOCKER and fix every instance of in. These blockers break the build and we are now assured that we wont add a new instance of the same issue again. This has worked great and has kept a number of what would be nasty bugs from slipping through.
The big problem with that methodology is we need to have an example of every one of those classes of mistake atleast once in the codebase so we could learn that it was important and should be made a blocker. Any issues we haven't already encountered will still be at their default level, I'd like to move all of them up to BLOCKER now so we notice the day they are added.
Edit: Currently we are using 3.7.3 but we are about to upgrade to 5.X.
There are 2 ways to do this:
1- The difficult way is to query the SonarQube database. You have to understand the tables and write a SQL query based on which DB is used for your SonarQube. You Can find some reference here - OR here
2- I have never tried your method but it should work. You can use Sonar Web Service API. You also have a Web Service Java Client. Reference :
link1,link2,link3
Related
Looking at eShopOnContainers, the microservice reference architecture from Microsoft. I see that for each service, in Program.cs a call is made to host.MigrateDbContext. This, in turn, executes all of the EF migrations for the given context.
In a real-world orchestrator isn't is possible that numerous containers for the same service could be spun up almost simultaneously? And if that happened, isn't it likely that multiple containers trying to execute the same migrations would deadlock or cause other issues?
Is this something that wasn't dealt with because it is beyond the scope of a reference project or does EF have something built in to handle concurrency that I'm not seeing?
I've found that there are numerous approaches to this problem, each with their own strengths and weaknesses. Some are straightforward... bringing the entire app down, updating schema, and then bringing the app back online. Some implement the schema changes as a series of smaller changes, each of which are both forward and backward compatible, allowing zero downtime. Still others leverage built-in or third-party tools written specifically to address this task.
So, to answer my own question, this topic was almost certainly omitted because it was beyond the scope of the eShopOnContainers project/eBooks. The right choice for you will vary based on your project's size, complexity, acceptable downtime, etc.
I noticed that after each sonar analyse, the use of the 'Sonar way' (Javascript) profile is switching.
Then each time it's re-enabled we have all JavaScript issues tagged as new!
What can be the cause of this behavior ?
How can I fix it ?
Thanks for any advice.
I see three possibilities:
you have someone with too much time on his/her hands manually flipping the configuration
you have sonar.profile somewhere in your analysis configuration. The question is how/why it would be getting set/unset
you have a person or more likely process that is resetting what the default JavaScript profile is.
I'm guessing there was some attempt to automate/ensure the use of the Sonar way profile that has somehow gone awry.
I would closely check your job configuration to see if sonar.profile appears anywhere in it and to see if there are any web services calls that might be (re)setting what the default is.
We are using SonarQube 5.1.1 and are analyzing some old legacy projects.
The problem is that we get a huge number of issues and would like to bulk change all of them as False/Positive and start from zero issues so we only get new issues and old ones that pop up again.
Is there a way to bulk change more then the basic 500 issues? If not in the web UI which tables in the database do we need to modify except the issues table?
This is a known limitation of the current architecture. It should be addressed in a near future.
Note that direct manipulation of the database is not recommended, this will introduce inconsistencies and make your instance unusable (especially due to the use of ElasticSearch for issues since SonarQube 5.0).
We're going to migrate our application from eXist-db 1.4.1 to ~2.2 (probably RC2).
I`m wondering if anybody already did such a migration and what impediments they met?
I already found some documentation about this on official website and tried to Google, but didn't find much. For now I know that there were significant changes in the security model and some APIs are also changed. But still I want to know if somebody investigated further or maybe can share success story.
The main difference between 1.4.1 and 2.1/2.2 is that stored XQueries now need the executable flag to be set. You can fix your permissions automatically using a query as described in the documentation.
It is also possible that some of your existing queries report errors on 2.1/2.2, which they did not before. In nearly all cases this happens because 1.4 was less strict about the XQuery specification and processed expressions which should not be allowed (the standard as well as the implementation evolved). Also, the query engine may now do additional checks to prevent potential issues. Usually the error messages by the compiler should directly lead to the code you have to fix. This may cost a few minutes, but it's worth the effort. Apart from this, no particular migration issues have been reported.
I'm currently evaluating a few different issue management tools, and have it narrowed down to TargetProcess, Redmine and Youtrack. For what I need TargetProcess seems to do everything with a lot less need for customisation, however as the only person working on QA at a small startup, I'm trying to make sure that as much of the process is automated as possible.
YouTrack has a workflow editor which allows you to write validation rules for your issues, and would therefore allow me to specify that you can't move an issue of a certain type into a certain state without having a related issue of another type, for example you cannot move a feature out of "New" without having a set of related requirements in the form of test cases.
While this isn't as ingrained in Redmine, there is a plugin which allows you to write these types of rules. I haven't however been able to find anything of the sort for TargetProcess, and worry that the ability to perform this sort of deep customisation will add an extra time-sink as I have to spend more time on this process myself.
Is there any way to achieve this in TargetProcess, be it using a plugin or an external service? I can see that I could hook something up to the REST api, but this would make it difficult to give feedback as to why an issue had not been progressed. TargetProcess is an impressive tool, however it is very expensive, and unless it does everything I want, it is difficult to justify the outlay.
TL/DR
Is there a mechanism for writing business rules into TargetProcess such that the proper QA process is enforced, so I can concentrate on providing value through QA rather than process management?
There are no customized Business Rules in Targetprocess so far. The only thing that exist is a Mashup that allows some rules customization related to custom fields
https://github.com/TargetProcess/TP3MashupLibrary/tree/master/Custom%20Field%20Constraints
Custom Business Rules are requested by many people and we are going to start development this year.