I already have a linter, I don't want the lint option

[brandtdaniels]

I am trying to use this step in conjunction with ensure git clean to make sure the devs run swiftformat before creating a PR.

The --lint option causes no files to be changed making this useless for me.

[dmiluski]

At present, this step is meant to ONLY verify the format requirements of the project

Inspired by: Swiftlint Step

It is meant to be used in tandem with additional formatting steps which could be applied with methods such as

• pre-commit-hooks (which can format prior to commit)
• danger step

Below are the contents of a pre-commit-hook script I include to be run on each commit. This does the heavy lifting while the CI step performs the validation in the event the hook wasn't installed

#!/usr/bin/env bash

# set -eo pipefail

## Evaluate Staged Files, Format lines changed, include in commit
git diff --diff-filter=d --staged --name-only | grep -e '\.swift$' | while read line; do
  swiftformat "${line}";
  git add "$line";
done

If you have thoughts on how to apply changes as part of the step itself, I'm more than happy to make them, or merge a suggestion.

[brandtdaniels]

Thanks, I have this pre-commit as well. On a large team however, you can't get everyone to install this.

[dmiluski]

@brandtdaniels very true. This step was originally meant as a secondary enforcement/reminder for developers in the event they cloned and didn't setup hooks as documented in a repo.

That being said, if you do have thoughts about how to apply a formatter. I'd love to learn your thoughts.

On an earlier attempt I was thinking about:

1. Determining if format was invalid
2. If invalid, format: but then, what could we do?

Commit to the branch another auto formatting commit? If so would there need to be special permissions? Forks? Branch protections?

This is something I'd love to refine an approach for given approaches I had not thought of.