So we use sonarqube/sonar in my current employer and have many existing projects on the sonarqube platform. I have been asked to go through these existing projects and ensure they have the buildbreaker plugin set to the default as some have been changed to true, the problem is they run into the hundreds and I don't fancy going through every project and checking this.
Is there a quicker way to change this? Maybe a script to run? A google search has revealed nothing, I am hoping someone has experienced this before.
Thanks.
Was actually ridiculously easy, setting>configuration>build breaker set to required value when not in a project will go back through all existing projects and change to the required settings.
This just means that to set an individual projects settings you will need to manually alter them again once you have changed the global settings.
Related
I've been having some difficulty with exclusions in SonarQube. I haven't really seen this particular situation posted here, and following some other solutions suggested in exclusion-related questions has not solved the issue. Any insight would be really appreciated.
I've been working with an engineer on filtering the files SonarQube is analyzing from their project during build time. Their solution is being built via a vNext build, where TFS and the build server are hosted on-prem. SonarQube is also hosted on-prem. The build is using the Sonar components included with vNext for the analysis. The project is primarily C#.
The solution consists of mostly projects exclusive to that solution, but there a few projects references that are part of another app entirely. Because of this, the workspace mapping has to get files from 2 separate parts of source control. Also, because of the way the solution is looking for the projects (based on the properties of the solution file itself), I have to map the source control files in a specific way. At a high level, the workspace on the build server looks something like this:
In the sonar settings file, the working directory is set to the Build Source Folder
The engineer wants to exclude code files from specific directories from analysis. For example, they want to exclude all cs files from folder X within B.Srvc. So, the directory would be Build Source Directory/B/Source/B.Srvc/X. Based on the exclusion instructions found on SonarQube's website, it sounded like I just needed to do something like this:
sonar.exclusions=Build Source Directory/B/Source/B.Srvc/X/**/*.cs
When I did that, it still analyzed the files within that folder. I tried various other combinations of patterns like:
sonar.exclusions=Build Source Directory/B/Source/B.Srvc/X/*.cs
sonar.exclusions=**/X/**/*.cs
sonar.exclusions=B/Source/B.Srvc/X/**/*.cs
sonar.exclusions=**/B/Source/B.Srvc/X/**/*.cs
I've even tried giving the complete directory path (so, C:/agent/_work/25/src/...) but that did not work either.
Very broad exclusions like **/* Name *.cs work perfectly fine, but if I want to start excluding files from certain directories, I can't get anything to work.
I feel like I'm missing something really basic, but I just can't figure it out. I've been trying to solve this issue for awhile when I have time, but I haven't made any progress. If anyone could provide any insight, I would really appreciate it. If you need any additional information, let me know.
In the SonarQube interface, look at one of the files you want to exclude. At the top, you will see the file path as SonarQube understands it. It is this path that you want to use when you enter your exclusions through the UI not the analysis settings.
Because of the structure of exclusion properties, they are very, very difficult to set up correctly in analysis properties. That's why doing so is not documented.
Instead, you should enter exclusions through the UI.
During normal development of any coded or configured project usually involves merging changes of some sort.
The same holds true for TeamCity build configurations themselves. Currently I'm failing to see a good way to do this in TeamCity. So far I've found a couple of primary ways to move a developed build configuration to a production usage.
These assume you already have a build configuration in use for production... i.e. it's not being actively modified or configured.
Make a copy of the build configuration A. We'll call the copy build configuration B.
Make your changes to configuration B and test them.
Now, there are two ways to get this back to the configuration A.
A. Delete build configuration A and move configuration B in.
doing this would remove any history of configuration A.
or
B. Manually, by hand, make the changed needed to configuration A.
This seems very error prone and lends itself to a great deal of human error.
If there is a better way to do this, or anybody has any thoughts, please let me know.
It is difficult to test your changes in isolation, especially when you use templates a lot and changing a template could affect a number of builds. In this scenario I normally detach the configuration from the template, make and test the changes. Then I reattach the configuration to the template and apply the changes at the template level. This then means I can then apply tested changes to DEV / TEST / UAT / etc configurations as they are all working off the same template.
TeamCity also has a really nice feature where you can sync your changes to your VCS - This mean that you can make changes in the UI or in code, and you have a history of your changes so you rollback edits to configurations quite easily.
I don't know if there's an optimum strategy, but the first option works for me, although I always have TeamCity write it's settings back to VCS where possible
Hope this may be of some help.
I currently have a SonarQube instance setup with multiple projects. Currently I get multiple requests every few weeks to update the quality profile to include a new rule or to remove an old one. This is usually followed by me having to recreate the projects and then sequentially running analysis again so that I can have the differential view again starting from a baseline code. This is becoming a pain as the number of projects grow. Is there any alternative to this? For instance is there any way to tell Sonar to pick up the new rules from the quality profile and run the existing analysis again against these rules.
If I don't do that I get a spike in issues as new rules get added and a new analysis is run as the existing analysis wasn't run against those rules and doesn't have an accurate issue number.
Thanks for the help!
Once you have linked a profile to a project, you can change the rule set and it will be used during the next analysis. As you add or remove rules, spikes are normal. Propably what you want to ensure is that for example no new rules are introduced as you want to ensure the quality is not going down, but is always improved. You can do it using quality gates and build breaker plugin. Hopefully I could help.
I am not sure to understand very well what you want to do, if this is running again a new (changed) profile to all previous versions of a project, or to apply different profiles on different versions of a project.
Maybe this could help you ?
SonarQube - analyzing branches of the same project
How to configure Maven to run a SonarQube project analysis with two different quality profiles?
I know I can instruct Maven to keep going after a failure with the -fae/--fail-at-end command-line option. Is there a way to set this behaviour as default for a given module?
Some background:
I'm moving from an Ant build to a Maven-based build, and the other developers on the team are used to the build completing even when there are failed unit tests. With a ~200-module product, the build takes a fair amount of time, and it would be ideal if developers could see all failing tests from the beginning, without having to remember to add the -fae option.
From reading the Maven docs, I get the feeling that the answer is a resounding "no", but I just want to cover my bases and make sure there isn't some sort of undocumented way to do this...
Thanks!
After checking out the Maven source code, I can confirm this cannot be configured by default.
An existing issue is opened on the Maven tracker: https://issues.apache.org/jira/browse/MNG-5342 (please vote if you still want it -- just noticed you did open it so you cannot vote on it ;) )...
Regards,
To skip test failures you can use property maven.test.failure.ignore. Of course you can use this property per module if you have parent and children poms.
I want to be able to build a web project and not its dependencies since I know that I have not modified any of the dependencies since the last build. I am looking to cut down the build time if possible. Is there a way to do this?
You could have a solution by
check the setting in Tools >> Options >> Projects and Solutions >>
Build and Run setting : Only build startup projects and dependencies on Run.
OR
If you want to go for sophistication then :
build >> Configuration Manager
from the "Active solution configuration:" dropdown select ""
give a name to your configuration and keep checked the "Create new project configurations" checkbox.
and then choose that config that you want and set the build or not check boxes.
To accomplish this in something I am working on, I created my own solution, added the projects I needed (including the projects I never wanted compiled), and then in the Configuration Manager turned off the check boxes for building the projects I didn't want to build, just as arora described above.
I've also made a copy of an existing solution (that had 16 components in it), saved it under new name (foo.sln -> foo.mine.sln), and then disabled the build of all the other sub-projects except the one(s) I am working on, that way I know for sure that I got the correct build settings.
It's not the simplest solution, but it works well for me, and takes less than 2 minutes to set up and is easy to understand. I normally add the new solution to the version control ignore list so that it never gets checked in.
Rather than project references you can just add the references to the dlls directly (the Add Reference dialog has tabs for these types, choose browse rather than project and remove the other projects from your solution). I typically create a full lib and web project solution for major development. Then just a solution for the website project for fixes where I don't need updated libs/dlls.
Although it is nice to have them autocompile if they have changed during heavy development. If they haven't changed it just refreshes them and recopies them to the bin folder.
Well one way would be to remove project references. Instead stick to dll references. You could use a post build script for dependent projects that copy the updated dll to the web project whenever they change.