Tuning Clean Code Workflows with Jenkins and WalkMod

In the Internet, there are tons of articles that outline the benefits of Continuous Delivery (CD). Among all the benefits of CD, it shines its ability for accelerating the pace of software delivery by having the code in an always shippable state.

Jenkins is an open-source automation tool with a powerful plugin architecture that helps development teams automate their software lifecycle.

Recently, Jenkins 2 has introduced a new concept called Pipelines; which specifies the set of stages a commit needs to pass before being deployed in the production environment. Organizations can define their pipelines by means of a DSL (Pipeline-as-code). Thus, pipelines can be versioned, checked into source and easily shared within an organization. For this tutorial, we are using Jenkins 2.49 with the default plugins and the Blue Ocean plugin.

In order to use Pipelines, you need a Jenkinsfile in the root folder of your Git repository and configure your Jenkins build to accept Pipelines.

A basic example for Maven projects that simply (1) runs mvn package — Build stage and (2) archive the resulting jar files — Result stage, would be:

Notice that we are not defining a Git repository. This information is defined in the Repository URL field during the job (project) configuration.

Static code analysis tools are typically used to break the build when new coding style violations appear. In Maven projects, these tools can be easily integrated using the corresponding plugins.

However, spending much time on fixing basic coding style violations — eg. removing dead code — ,sucks.

In fact, this is the reason why this kind of checking tools are usually avoided, especially in projects with a seed status. After a while, they report thousands of hours of technical debt.

WalkMod, is an open source tool to apply quick fixes on Java code. This tool can save amounts of hours of manual fixings of coding style violations reported by common static code analysis tools such as PMD, CheckStyle or SonarQube. WalkMod can be easily integrated in Maven and Gradle projects. In the first case, add the following plugin into your pom.xml.

Plugin to include in pom.xml

Additionally, we need to configure the set of WalkMod fixings to perform as a “project properties” in our pom.xml. For instance, the following snippet defines that we want to fix the pmd violations defined in the ruleset.xml file. If you want to use the default PMD ruleset, discard the last property.

Now, by running Maven, we can generate a patch (called walkmod.patch), that contains fixings for the existing issues in our repository.

mvn walkmod:patch

If we decide to apply that patch into our Git repository, and push WalkMod changes, we need to run the following commands:

git apply walkmod.patch
git commit -a --fixup HEAD
git pull --rebase origin $branch
git push origin HEAD:$branch

Automating these steps as part of our continuous delivery pipeline, helps ensuring a high quality of our code base. In order to avoid repeating these same steps across all your projects, we have built a Jenkins pipeline library that can be easily integrated into your Jenkinsfile as follows:

@Library('github.com/walkmod/jenkins-pipeline-shared@maven') _

Now, you can add a new stage called “Fixing Release” that simply contains a call to our library using the Jenkins declarative syntax for closure calls:

walkmodApply(
validatePatch: false,
branch: env.BRANCH_NAME,
alwaysApply: true,
alwaysFail: true )

The walkmodApply call receives (validatePatch) if we want to wait for user validation before pushing our changes into the repository; (branch) the branch where it pushes the changes; (alwaysApply) if the path is always applied and (alwaysFail) if the build fails after the build is successful. This WalkMod API accepts many other calls that you can check in our GitHub repo.

And voilà!, we can now run integrated quick fixes on our build! Additionally, if we start our build from the Jenkins Blue Ocean UI, we can see how initially, our pipeline fails because there is a pending walkmod patch to apply, and finally, if we run again the build — since there is a new fix-up commit that fixes our coding style- our build becomes green.

Finally, if you install the HTML Publisher Plugin in your Jenkins, you will be able to see the last patch applied — if a build fails- in a beautiful diff format.

WalkMod patch fromJenkins UI

If you would like to check a more concrete example, use the rpau/age-checker-service repository.

Legacy code requires to apply patches incrementally when the included changes are under test coverage. If this is your case, we have designed WalkModHub for this purpose. It is a tool that can freely download and evaluate as a Docker container.