Groovy Linting

Groovy Linting Tools

2024-08-02 (Last Modified: 2024-09-06)

Page content

I’m currently working on a Jenkins-based CI Automation Server. When developing a new CI pipeline, I always advocate for the Pipeline to be configured as code. This allows it to be reviewed before applying it and introduces a historical change set. I’ve not made complex Jenkins scripts before, but this was required for this project.

So, what is the problem with this process? Well, I’ve never really worked with Groovy before and needed to understand the programming language. I inherited a code base that did not really account for treating a Pipeline as a product, so I need to introduce my own process for handling it as a product.

When you treat your pipeline as a product, you start to introduce normal software development activities into the change process. These can include things like static code analysis and testing. With static code analysis, you have two major types: stylistic and logical. The stylistic portion of static code analysis is typically around how you should format your code based upon company standards. These standards are so when a new person onboards to the code base, you don’t have to re-format the code to someone’s preference. The logical part of static code analysis relates to the programmatic usage of the code. This can include, but are not limited to, functional usage and parameters, standards for opening/closing functions, and programming language usage.

Groovy Usage

We have a repository that controls almost all of our product code and utilities to build, test, and deploy the production code. This is typically a mono-repo style set up. When a developer introduces changes, there is a algorithm to determine what should be built, what should be tested, what should be retained, displayed, or reported. This code is a combination of Python tools, BASH scripts, and Jenkins supported Groovy scripts.

The Groovy scripts utilize inherit Jenkins functions and utilities and are written in the Groovy language. Groovy is based upon Java, so you will see a major influence in the coding style.

Groovy Linting tools

NPM Groovy Lint

I stared with a simple search and came across the following command:

docker run \
    --rm \
    --user "$(id -u):$(id -g)" \
    --workdir /tmp \
    --volume "$PWD":/tmp \
    nvuillam/npm-groovy-lint

or a one line of:

docker run --rm -u "$(id -u):$(id -g)" -w=/tmp -v "$PWD":/tmp nvuillam/npm-groovy-lint

It worked perfectly.

First this will mount your current directory as a volume to /tmp and ensure that your current user and group ID are passed to the container. Then it will find all of the Groovy files, including Jenkinsfile, in your current directory then reports what issues you may have with your files.

It will give you the errors, warnings, and informative changes that need to be updated as part of the linting process. Ideally, just focus on the errors and move on with your life for the time being.

Configuration File

In the calling directory, you can play a configuration JSON file.

VS Code Plugin

Groovy Linting as part of your development Process

This tool is great and all, but really we need to run this automatically in order to get any feedback from our team so we don’t push poor code to everyone else.

That means we should “shift-left” to have the linting done as part of your normal development environment.