Don't run code formatting in your CI pipeline

Something I commonly used to see, and did myself, was running code formatting tools, such as PHP CS Fixer or prettier, automatically their CI pipeline.

And not using it as a check to fail the pipeline if your code isn't formatted correctly.

Running it, fixing any code and committing any updates.

It wasn't long before I stopped doing this.

Firstly, I wasn't comfortable with a CI pipeline have write access to my codebase. It's fine to be able to clone it and run checks against it, but making changes to my code and pushing it makes me nervous.

Particularly if you're doing trunk-based development and everyone works on the same branch.

This also causes additional upstream commits, because the pipeline has committed a change. If you don't remember to pull those commits, you can end up in a tricky situation.

I'm also not a fan of having a lot of php-cs-fixer fixes or prettier fixes commits. I'd prefer the commits be correct when they're pushed, if possible, which is why I usually do micro commits locally and tidy things before pushing them.

If you're working on a topic branch and creating a pull or merge request, you can squash commits when merging, but I'm not a fan of squashing commits, either.

Instead of relying on a CI pipeline to run code formatting, make it easy to run those tasks locally.

- Oliver

Was this interesting?

Sign up here and get more like this delivered straight to your inbox every day.

About me

Picture of Oliver

I'm an Acquia-certified Drupal Triple Expert with 17 years of experience, an open-source software maintainer and Drupal core contributor, public speaker, live streamer, and host of the Beyond Blocks podcast.