Simple guide to configure code formatter

How To Enforce Formatting in Continuous Integration

Vadym Perepeliak
Dec 2 · 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

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.

Let’s create our .editorconfig file

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.

Share code style with the team

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.

Gitlab CI Configuration

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

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

Medium's largest active publication, followed by +536K people. Follow to join our community.

Vadym Perepeliak

Written by

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

The Startup

Medium's largest active publication, followed by +536K people. Follow to join our community.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade