Check if Pull Requests violate EditorConfig rules with Azure DevOps Pipelines

If you work in a project with multiple different developers, you might be using EditorConfig to standardize the coding styles and file formats across your team members. EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs. Although EditorConfig does a great job here, it only checks for violations locally and only if a developer’s IDE supports it natively or through a plugin. So it could be easily ignored or disabled.

If your OCD is demanding like mine, you cannot accept that! So I created an Azure DevOps Build Step, that checks every incoming Pull Requests for rule violations and lets the build fail if it finds some.

Create a new Pipeline for EditorConf checks

Of course, you could also integrate this into an existing pipeline, but I wanted to keep it separated from my actual build pipeline, because the projects usually build even with style guide violations and I wanted to be able to decide to release anyways.

Add a new Bash task (runs on all platforms) and paste the following script inline, which downloads the Node.js module eclint and executes it against all files, that are part of your git repository (and not ignored).

# Install eclint 
npm npm install -g eclint 

# Check src folder for EditorConfig violations 
eclint check $(git ls-files)

Make sure, to also have the Fail on Standard Error option from the task’s Advanced settings enabled, to make sure the build fails, when the script detects rule violations and writes them to the command line as an error.

If you prefer creating your Build Pipelines with YAML, you can find this build definition as code here.

Checking Pull Requests

If you want to make sure, that all incoming Pull Requests will be checked for EditorConfig violations, just head over to the Triggers tab of your Build Definition and activate Enable pull request validation for it.

GitHub, for example, from now on will trigger the Pipeline for every incoming Pull Request and display the result inside the Pull Request overview. Again, it is useful to have the EditorConfig Check in a separate pipeline, so I can still decide to accept the changes anyway.

Let’s keep our fingers crossed, that the overall code quality in this world becomes a little bit better with that!

☝️ Advertisement Block: I will buy myself a pizza every time I make enough money with these ads to do so. So please feed a hungry developer and consider disabling your Ad Blocker.