Simple guide to configure code formatter
How To Enforce Formatting in Continuous Integration
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.
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.
File’s content would be similar to that one presented below:
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?
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 pipelinenpm install -g eclint— as the first step we must install eclint tool in the pipelineeclint 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.
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 fileThen let’s change a bit .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.
