2

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:

  1. 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.
  2. How can you actually compare if actually the amount of "warnings" has decreased from one build to another? (Considering the above described as ratcheting )
Improve this question

1 Answer 1

Reset to default
2

Regarding question 1: You could give the Warnings Plugin a try.

Regarding question 2: Configure your SonarQube project, to have a Leak Period since "previous build"

The SonarQube Leak Period specifies the time frame of your usual development cycle. Quality Gate conditions can be specified to be specific to that time frame, to enforce your quality to "get better" over time.

If you for example want, that your test coverage increases from version to version, you can set your Leak Period to "since last version" and define a Quality Gate condition on the leak for the coverage metric.

Read more about it in this official statement about the Leak Paradigm.

Improve this answer
5
  • I'll give it a try to that plugin. Can you please elaborate on the "leak period" term? Is it related also to the warnings plugin?
    – gvasquez
    Commented Oct 18, 2017 at 14:42
  • 1
    @gvasquez I updated my answer - feel free to ask if any question remains open!
    – slartidan
    Commented Oct 18, 2017 at 15:20
  • Much clearer the term Leak Period, but as question 1 is directly correlated with question 2, and the Warnings are Jenkins log related, how does this match with Sonarqube analysis/reports?
    – gvasquez
    Commented Oct 18, 2017 at 15:23
  • 1
    Oups, you are absolutely right :) The Leak Period can help you to fail if there are new SonarQube warnings, but not compiler warnings. So your question actually is not related to SonarQube at all, right?
    – slartidan
    Commented Oct 18, 2017 at 15:54
  • We do use Sonar, but it just part of the whole process, as Jenkins encapsulates several tasks that might generate warnings...those are the warnings to be considered
    – gvasquez
    Commented Oct 18, 2017 at 16:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.