Having a build fail because a coding standard is violated is nice. However, when introducing checkstyle to a new project, there might be a lot of violations.
Instead of adding one and one rule, does anyone know of a (preferably simple) way of setting up something that will fail the build only if more warnings are introduced than were there before?
This is not possible. But as a workaround you can specify maxAllowedViolations (and maybe reduce this number manually with every check-in).
Related
So, I have an interesting situation. I have a group that is interested in using CI to help catch developer errors. Great - we are all for that. The problem I am having wrapping my head around things is that they want to build interdependent projects isolated from one another.
For example, we have a solution for our common/shared libraries that contains multiple projects, some of which depend on others in the solution. I would expect that if someone submits a change to one of the projects in the solution, the CI server would try to build the solution. After all, the solution is aware of dependencies and will build things, optimized, in the correct order.
Instead, they have broken out each project and are attempting to build them independently, without regard for dependencies. This causes other errors because dependent DLLs might not yet exist(!) and a possible chicken-and-egg problem if related changes were made in two or more projects.
This results in a lot of emails about broken builds (one for each project), even if the last set of changes did not really break anything! When I raised this issue, I was told that this was a known issue and the CI server would "rebuild things a few times to work out the dependencies!"
This sounds like a bass-ackwards way to do CI builds. But maybe that is because I am older and ignorant of newer trends - so, as anyone known of a CI setup that builds interdependent projects independently? Any for what good reason?
Oh, and they are expecting us to use the build outputs from the CI process, and each built DLL gets a potentially different version number. So we no longer have a single version number for the output of all related DLLs. The best we can ascertain is that something was built on a specific calendar day.
I seem to be unable to convince them that this is A Bad Thing.
So, what am I missing here?
Thanks!
Peace!
I second your opinion.
You risk spending more time dealing with the unnecessary noise than with the actual issues. And repeating portions of the CI verification pipeline only extends the overall CI execution time, which goes against the CI goal of reducing the feedback loop.
If anything you should try to bring as many dependent projects as possible (ideally all of them) under the same CI umbrella, to maximize the benefit of fast feedback of breakages/regressions on any part of the system as a whole.
Personally I also advocate using a gating CI system (based on pre-commit verifications) to prevent regressions rather than just detecting them and relying on human intervention for repairs.
I want sonar scanner to run on a legacy project but capture only new issues. Is there a way to mark and neglect all the existing legacy issues ?
Yes, you can exclude those files from scan.
From project settings you can exclude, you can choose to exclude only for issues or you can totally exclude the file (no metrics is generated - loc, complexity, duplication nothing is calculated)
If first analysis has not happened use provisioning to achieve the same.
Updating to cover peculiar case of excluding only old issues:
By marking all old issues as false positives you'd exclude them from future analysis, though might sound like bonkers it will work as long as don't change directory structure.
Sonar analysis is a nice way to check code compliance against a centrally defined policy. This is why I would like to use a profile with Blocker a Critical rules to signify a broken build.
I am using Jenkins do builds and invoke the SonarRunnerBuilder to get standard analysis on nightly builds of projects.
To achieve the features I outlined it would be best if I could run the analysis, check the results for violations (preferrably not sending them to Sonar server) and fail the build if there were any violations. So far I have not found way to do this using Google and looking through SonarRunner source code.
What I have considered is a workaround. I would implement a Decorator collecting violations and when the decoration reaches the project resource I would throw a RuntimeException to break the analysis. This would in turn fail the build.
would this work? Is there any better way to achieve this?
What you are looking for seems to be what the build breaker plugin offers. It relies on the Quality gate configuration to detect when violations (now called issues) in the current analysis require to break the whole build.
Please consider that this plugin won't be supported in SonarQube 5.2. Technically, deep changes in SonarQube's architecture make it impossible to provide the same feature. Philosophically, this plugin does not match the experience SonarQube wants to offer.
Still, another solution which covers the same use case is very likely to be offered in future version of SonarQube but this is yet to be defined.
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'm playing with the wonderful FindBugs plugin for Hudson. Ideally, I'd like to have the build fail if FindBugs finds any problems. Is this possible?
Please, don't try and tell me that "0 warnings" is unrealistic with FindBugs. We've been using FindBugs from Ant for a while and we usually do maintain 0 warnings. We achieve this through the use of general exclude filters and specific/targeted annotations.
The hudson way is to use unstable and not fail for something like this.
However if you really do want your build to fail, you should handle this in ant.
<findbugs ... warningsProperty="findbugsFailure"/>
<fail if="findbugsFailure">
Maybe you've already seen this option, but it can at least set your build to unstable when you have greater than X warnings. On your job configuration page, right below the Findbugs results input field where you specify your findbugs file pattern, should be an 'advanced' button. This will expand and give you an "Unstable Threshold" as well as Health Reporting that changes Hudson's weather indicator for the job based on the number of warnings.
I wouldn't want my build to fail, but unstable seems reasonable if you are maintaining 0 warnings (and presumably 0 test failures).
As Tom noted, the provided way to do this is with the warningsProperty of the FindBugs ant task.
However, we didn't like the coarse control that gave us over build failure. So we wrote a custom Ant task that parses the XML output of FindBugs. It will set one Ant property if any high priority warnings are found, a different property if any correctness warnings are found, a third property if any security warnings are found, etc. This lets us fail the build for a targeted subset of FindBugs warnings, while still generating an HTML report that covers a wider range of issues. This is particularly useful when adding FindBugs analysis to an existing code base.
You can not rely on find bugs so much , it is just an expert system that tells you that something may be wrong with your program during runtime. Personally I have seen a lot of warning generated by findbugs because it was not able to figure out the correctness of code (in fact).
One example when you open a stream or jdbc connection in one method and close it in other, in this case findbugs expecting to see close() call in same method which sometimes is impossible to do.