Simple guide to configure code formatter

How To Enforce Formatting in Continuous Integration

Vadym Perepeliak
Dec 2, 2019 · 4 min read
Photo by Marvin Meyer on Unsplash

Have you ever commit indent changes?

If so, you rather don’t have configured formatter in your project or not everyone uses it. Lack of formatter leads to frequent changes in huge amount of project files. It’s a good practice to have formatter in the git repository to avoid unneeded changes and to save time e.g. fixing indents in .yml files.

This story will cover Java code formatter in IntelliJ and Format check in Continuous Integration pipeline. I picked Java cause there is a limited info in the community on how to proceed with it the best way. Steps described in this story are easily applicable to any language.

💡 By the way, formatter is a right tool to resolve endless debate in programming world: tabs vs spaces. Of course I’m kidding but at least it could be done in your team.

Java code formatter in IntelliJ

It was really hard to find the right tool to format Java project. There are some criteria I was looking for:

  • formatter must cover Java and other file types e.g. .yml, .xml, .json
  • there must be CLI to run it in Continuous Integration (CI) pipelines
  • it would be nice to have formatter plugable in IntelliJ so it could work on the fly while typing

However there are some tools specific for Java code like PMD and checkstyle, they couldn’t cover other file types. At the moment of publishing eclint is the tool that best matches my criteria. It could be configured using .editorconfig file. Although eclint doesn’t have native support for Java files, IntelliJ supports .editorconfig configuration out of the box.

I think that IntelliJ by default has pretty good formatter. The good news is — we could export it to .editorconfig file. Just go to Settings → Editor → Code Style and then select Export → EditorConfig file. Save the file to project directory.

Export code style in IntelliJ

File’s content would be similar to that one presented below:

Sample of .editorconfig file

As you could see configuration properties are pretty meaningful. There is documentation for them. Also there are properties that starts with ij_java_... Those are supported only by IntelliJ and couldn’t be migrated to any other IDE.

We could enforce IntelliJ use properties in .editorconfig file in project directory over current code style schema by toggling checkbox “Enable EditorConfig support” as shown at the screenshot above. As from now, any changes in code style must be done in .editorconfig file.

Now we could commit the file and push it to repository so everyone could use it with new code. It will be good to reformat all files in the project by selecting them in IntelliJ and press Ctrl + Alt + L.

Format check in Continuous Integration pipeline

It is very conveniently to have auto-format when you work in IDE. But what about cases when you edit something in other editor or even in GUI at your git server? No doubt such inputs must be checked with code style definition. Continuous Integration pipeline is here to rescue. In this section I will show you how to set up format check in CI pipeline using Gitlab CI pipelines.

Please take a look at configuration file below. It is really minimalistic, isn’t it?

.gitlab-ci.yml file

There is a brief description of code pieces in the .gitlab-ci.yml file:

  • tarampampam/node:8-alpine — it is docker image available at Docker Hub with installed node v8. This docker image is used to run pipeline
  • npm install -g eclint — as the first step we must install eclint tool in the pipeline
  • eclint check $(git ls-files)does real work, checks formatting of all files covered by git

And that’s it, our automated check in pipeline is configured. In case of wrong files formatting pipeline will fail and it will list invalid files in the log.

Pipeline log from gitlab.com

More about .gitlab-ci.yml file you could find at docs.gtilab.com.

Bonus: .editorconfig-ignore file

As you could see in pipeline log, gradle wrapper file named gradlew has invalid formatting. It is auto-generated file, therefore we would like to ignore it from been checking by eclint in pipeline. What could we do?

Let’s create file named .editorconfig-ignore at the same directory level as .editorconfig file.

.editorconfig-ignore file

Then let’s change a bit .gitlab-ci.yml file.

Changed .gitlab-ci.yml file

Pay attention to how last line was changed. We just filtered out files specified in .editorconfig-ignore file from being listed by git ls-files command.

Now it is ready to be merged to your project’s master branch.

This story shows only sample of formatter configuration. You could find real-live advanced configuration of formatting check at this open-source project: https://gitlab.com/smasly.com/smasly-event-api.

Resources

The Startup

Get smarter at building your thing. Join The Startup’s +725K followers.

Vadym Perepeliak

Written by

Software Engineer with love for CI/CD | Creator of smasly.com

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +725K followers.

Vadym Perepeliak

Written by

Software Engineer with love for CI/CD | Creator of smasly.com

The Startup

Get smarter at building your thing. Follow to join The Startup’s +8 million monthly readers & +725K followers.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store