I've setup a build job in Travis with the Sonarcloud plugin so that it analyzes one of our C/C++ projects, links:
GitHub source - https://github.com/inilabs/libcaer
Travis job - https://travis-ci.org/inilabs/libcaer/jobs/247488797
Sonarcloud - https://sonarcloud.io/dashboard?id=com.inilabs.libcaer
Now if I run this with the default C quality profile "Sonar way" it works fine. Then I created a test profile where I added a one rule and deleted another, and this also worked, so basic custom quality profiles seem to work fine. Then I created our main quality profile "inilabs" that I want to use, where many more rules are enabled (~50) and several (~10) are disabled. Surprisingly this build fails during the 'sonar-scanner' step, with the following exception:
java.lang.IllegalStateException: Unable to load component class org.sonar.scanner.report.ActiveRulesPublisher
(see the above linked build for full error, run with 'sonar-scanner -X)
It seems to get the files with the custom quality profiles fine, so the only thing I can think of is that there must be a specific rule in one of the ~60 changes that makes this fail, but I have no clue how to debug this to understand which one it is. I hope you can help me in pinpointing the problem, thanks!
The error is due to some deactivations of rules in your Quality profile, for example see "restrict should not be used" in the changelog: https://sonarcloud.io/organizations/inilabs-github/quality_profiles/changelog?language=c&name=inilabs.
This bug is tracked in https://jira.sonarsource.com/browse/SONAR-9489 and will be fixed as soon as possible.
A workaround is to copy the profile to another one. Corrupted rules won't be copied.
Sorry for the inconvenience.
Related
SonarQube Quality Profiles are not being used during the sonarqube scan:
We have sonar tasks installed and enabled for build definition what we are seeing is that the quality profiles are being stopped for one build run and it is again started using the quality profiles for the next run automatically. We are consistently seeing the same behavior for the alternate build runs.
Image where we can see the profiles are stopped and started:
What you're seeing is the result of a bad configuration somewhere. You indicate your comments that along with the toggling of profiles, you also see large swings in issue counts
as most of the file types get excluded from analysis resulting in very few issues reported.
So let's break this down:
The profile events you're seeing simply record/reflect the changes in profile use from one analysis to another. If I have a project with Java and JavaScript, the first analysis will use the default profiles for that language. Then, let's say I use the deprecated property sonar.language to restrict analysis to just Java files and analyze again. Since JavaScript is no longer found in my project, the default JavaScript profile will not be used, and a profile event will be recorded.
That seems to be what you're seeing in your activity log.
So now to the detective work: why is this happening? First, this swings back and forth. That indicates configurations set not at the project level (in SonarQube itself) but properties that are only sometimes passed during the analysis, or some other analysis-side circumstance. There are a few possible causes which you'll need to investigate independently:
sonar.language - if this deprecated property is used during analysis, it will limit the by-default multi-language analysis to a single language. It could be in your properties files or passed on the analysis command line -Dsonar.language=foo
exclusions - exclusions are difficult to set properly from the analysis side, but this can happen
improper/incomplete checkout - is it possible that only part of your project is checked out?
In investigating this, you should be aware that analysis-side properties can be set at two levels; at the individual project/analysis or in the global scanner configuration.
I'm guessing that your CI system has multiple slaves and languages are dropped - or not - from your project depending on which slave the job lands on that night.
I was experiencing a similar problem and I believe I have tracked down the root of the issue for us. Capturing the source code and properties used during the build, I was unable to find any discrepancies in sonar properties or source code collected, as suggested in the previous answer.
Our solution we were trying to analyze with SonarQube has a few C# projects that are part of an external core solution, which is shared between several components. Compiling any one of these other components requires that core be compiled first. I believe the issue lies in that when compiling my component to be analyzed, MsBuild would sometimes rebuild some of the projects included in core. Depending on if they were rebuilt or not, the number of projects and files (and hence issues) would swing wildly in one direction or the other.
By enforcing MsBuild to clean my component solution before compiling,
MsBuild.exe MySolution.sln /t:Clean,Build
I ensure a consistent set of projects are built and analyzed by sonarqube. I am 30 builds in with this new approach and I have no more flopping back and forth between using and not using a quality profile.
I'm trying to create method without add comment or documentation it, I expected SonarLint would show errors based on rules, but I don't see any errors or warnings. Why?
The particular rules you're looking for are "common" rules applied at the server. You're not going to see them in SonarLint. But in general:
Out of the box, SonarLint runs with the Sonar way (default) profile. If you want additional rules applied in the IDE, you'll need to:
set up a SonarQube instance (assuming you don't already have one)
configure a Quality Profile to your liking
apply it to your project
connect your project in the IDE to the project on the server
At this point you will see (almost) all the same issues in both places.
I want to use a specific sonar profile with analysis mode preview for generating comments that go into our github pull requests.
The default quality profile for the project includes minor and info level rules which will cause hundreds of extra comments (and literally thousands of github notification emails). So it has to be a quality profile specific to this purpose.
Running the build like this:
mvn sonar:sonar -Dsonar.profile.java=PRComments -Dsonar.analysis.mode=preview
Fails with the following error:
sonar.profile was set to 'PRComments' but didn't match any profile for any language.
The PRComments quality profile exists and works perfectly if I don't specify the preview mode. And yes I know that -Dsonar.profile is deprecated and it makes me sad too.
For info I'm using the sonarqube github plugin http://docs.sonarqube.org/display/PLUG/GitHub+Plugin to push the comments into github - but the failure above appears even if I don't use this plugin. Unfortunately the github plugin doesn't seem to have an option to skip adding comments for violations below a configurable severity level.
Is this possible or do I have to give up?
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.
My Hudson projects don't seem to properly aggregate downstream test results and I'm wondering if I've missed a configuration step somewhere. I have two projects, Foo and Foo-Tests, both of which are freestyle jobs.
On project Foo I have the following configuration:
Checked "Aggregate downstream test results".
Checked "Automatically aggregate all downstream tests" under the previous option.
Checked "Build other projects" and specified "Foo-Tests" to build.
On project Foo-Tests I have the following configuration:
Checked "Publish JUnit test result report" and specified my JUnit report XML files.
When Foo builds, it builds successfully and correctly triggers a Foo-Tests build. The Foo-Tests build is successful and publishes the JUnit reports correctly. However, when I look for the aggregated test results in Foo, there's a "Latest Test Result (no tests)" link for the build which sends me to a 404.
Here's what I've tried that doesn't solve the problem:
Tell Foo to "Publish JUnit test result report" with no parameters (there are no tests in project Foo, just Foo-Tests). This caused an error since there were no test files for it to process within the project.
Tell Foo-Tests to "Fingerprint all published artifacts" with no parameters (I was wondering if Hudson treated JUnit reports as artifacts behind the scenes). This caused an error since I hadn't explicitly defined any artifacts to publish.
I'm using Hudson 1.266.
Edit:
I should note that I've found two questions on the Hudson Users mailing list that have no answers and would possibly help solve this:
Question 1 (Nabble)
Question 2 (Nabble)
We're using Hudson ver. 1.324 and had similar trouble. Although you mention that you tried enabling fingerprinting and it didn't work for you, it did for us. We followed the instructions found here:
http://shotgunsandpenguins.blogspot.com/2009/07/how-to-aggregate-downstream-test.html
I was able to replicate your problem with Hudson 1.266. This a Hudson error, which was fixed in a later build (prior to 1.287), so either upgrade Hudson or use this two-click workaround: from the Project page, go first to Latest Build and then Aggregated Test Results.
The problem is that the Project page for Foo is only showing the Latest Test Results link, which has a URL like http://localhost:8080/hudson-1.266/job/Foo/lastBuild/testReport/. Since Foo has no tests of its own, this link has no JUnit XML file to reference and returns the error you mentioned. This was fixed somewhere between 1.266 and 1.287 by redirecting from latestBuild/testReport/ back up to latestBuild/ when there are no tests. The alternative for you in 1.266 is to, instead of clicking on Latest Test Results in the Project page, scroll down a bit and click on Latest Build under Permalinks. This will take you to the latestBuild/ URL, and from there you can click on Aggregated Test Result, which has a URL like http://localhost:8080/hudson-1.266/job/Foo/lastBuild/aggregatedTestReport/. On this page, all your test results from downstream projects will be available under the Drill Down section.
Unfortunately, there is still a problem with the Drill Down links, even in 1.287. From Foo, when you drill down to Foo-Tests as outlined above, you will be taken to a malformed URL, which looks like http://localhost:8080/hudson-1.287job/Foo-Tests/. You'll have to manually modify that URL to insert a / between the hudson context and the job path following it so that it looks like http://localhost:8080/hudson-1.287/job/Foo-Tests/. Then you will be able to actually see the downstream test results.
I haven't had a chance to look through the Hudson source to find the error, but there's already an issue open for this. Its issue 1574, and its been open for almost a year.
On a side note, I really love Hudson for CI, but their interface isn't as smooth as it could be. I look forward to their rework of the UI in ExtJS. Maybe thats what they're spending all their time on.
I fixed the missing '/' issue in Hudson 1.288
The key to using the aggregate downstream tests results is to run fingerprinting on both jobs. In this case, that would be 'Foo' and 'Foo-tests'
Hudson matches up the build with the downstream tests by finding files with identical fingerprints. So this means your fingerprints have to match. Kind of like a crime scene.
the two projects, Foo and Foo-Test, have to know they're on the same stream, so it takes fingerprints (and therefore archiving) of a common file.
i had to pick a file that didn't change between the running of Foo and Foo-Test, and still changed between times they are both run. for me that was an unrelated, temporary .jar generated by Foo in the custom/common workspace for my versions of Foo and Foo-Test.
i.e., i had to let both Foo and Foo-Test fingerprint the same file.
after that, at least with hudson 1.330, things work - aggregated links, drilldown, etc.