I've been reading the book "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Addison-Wesley Signature Series (Fowler))"
And these paragraphs drew my attention:
Compiler warnings are usually warning you for good reasons. A strategy that we have adopted with some success, though it is often referred to as the “code Nazi” by our development teams, is to fail the build on warnings. This can be a bit draconian in some circumstances, but as a way to enforce good practice it is effective.
As we have said, for some projects failing the build on any warning may sound too draconian. One approach that we have used to introduce this practice gradually is ratcheting. This means comparing the number of things like warnings or TODOs with the number in the previous check-in. If the number increases, we fail the build. Using this approach, you can easily enforce a policy that every commit should reduce the number of warnings or TODOs at least by one.
In our scenario, we are using Jenkins integrated with SonarQube, mainly with Maven Java projects and, seems quite interesting to achieve the behavior suggested in the above-quoted paragraphs, so I have a few questions on that subject:
- How can one configure Jenkins for a build to fail when it detects some tag (e.g. "[WARNING]) in the log output? Fox example a deprecated API, or a Maven relocated artifact perhaps.
- How can you actually compare if actually the amount of "warnings" has decreased from one build to another? (Considering the above described as ratcheting )