Why would you run code formatting tools in a CI pipeline? If the code had been committed in the wrong format the problem should be addressed before the code goes into version control. Stuff like this helps with maintaining a tidy history and consistent code base. Sounds like self inflicted wounds to me.
The workflow is: You create a git branch, commit your changes to it and push them to the repo server. The CI then checks whether the code is formatted as expected. If the code is incorrectly formatted, the CI job fails and prints the format error(s). When the code is formatted properly (no CI jobs fail), you are allowed to merge into the master branch.
Reading your comment I assume you want the repo server to reject incorrectly formatted code at push time. Rejecting commits/pushes has the disadvantage that you cannot share your code/branch with others (or yourself on other devices), and cannot back up your code to the repo server.
You could argue formatting doesn’t take long. I’d argue, the repo server shouldn’t keep me from publishing code to a dev branch.
I review code. If the code is improperly formatted I know the person isn't using the right formatting tools and I tell them to fix that. In general I trust my team to actually use our code formatting tools and follow guidance.
Running a formatter in CI and failing the build if it finds anything is a good way to make sure people are running the right tools locally, which is in turn a good way to maintain quality. I've seen many devs work with broken environments and just ignore the problems because it doesn't actually stop them, or because they don't realise it's broken.
> I've seen many devs work with broken environments and just ignore the problems because it doesn't actually stop them, or because they don't realise it's broken.
That sounds like an educational issue. I work in a small team in a small organization.
