In progress of moving to ktlint but trying to ensu...

# ktlint

[Justin Tuchek]

In progress of moving to ktlint but trying to ensure open PRs are based off latest master that contains new formatting hooks - is there a quick way to determine if ktlint has been run over a set of files?

Doing a single reformat but typically have ~30 PRs merged per day so some chance for unformatted ones to slip through (require keep branches up to date is a different challenge)

In my head an idea looks a bit like ./ktlint check <git-commit-range> and returns back an exit code of 0/1 based on the files in the diff. Maybe somebody has a better way for handling this? Or a solution already exist I’m unaware 🤔

Incremental would be great to minimize build impact, running with --format takes ~25 sec. If it was fast enough would consider just leaving it in to catch environments that haven’t set up hooks yet and post a comment on the PR

[Sha Sha Chu]

i’ve never personally used it, but ktlint does support a precommit hook via the installGitPreCommitHook command. i believe it only checks the files in your commit

[Justin Tuchek]

The precomit hook looks nice - was thinking about the case of getting a PR that hasn’t been formatted, such as a new teammate who hasn’t set it up yet

[Colton Idle]

I recently started using installGitPreCommitHook. If I recall correctly, then yes it only runs on changed files.

[Justin Tuchek]

We're using a precommit hook

Previously used 'gradle spotlessCheck' in our CI to determine if a PR was properly formatted or not

Was able to get something working with ktlint's json reporter to determine if a change set wasn't using the precommit hooks/formatter and leave a PR comment about setting up ktlint in their dev environment

[Craig Berry]

late to this but, can you use something like github actions to run ktlint separately? you can have it be a required check to merge the PR

[Colton Idle]

We run ktlintCheck on CI (haven't used github actions) but yes it'll fail our build. We just don't want to wait until CI when it can be done in about 2-3 seconds locally.

[Craig Berry]

gotcha, we also run using the precommit hook. just thinking integrating with the CI would fix @Justin Tuchek problem if a new dev somehow bypasses the linting

[Justin Tuchek]

Yes - running on ktlint in CI would solve the problem

Just trying to understand if there was something out of the box with a pass/fail status

The options I’m aware of right now put that work back on the user to determine if there are issues or not to surface from CI
• parsing the report output
• running ktlint and checking for changed files
Also new to the tool, so wiling to admit I may be missing some things 🙂

[Craig Berry]

we just brought this into our workflow but chose not to lint the entire codebase at once. so instead of making part of the build we are using precommit hooks to just lint a users changelist. we install ktlint as part of our gradle build, but only run it as part of the commit hooks

[Craig Berry]

a user can still bypass it but they have to use --no-verify or something similar. so it would need to be a conscious decision to get around the linting, but otherwise they would get it by default before going to PR

[Colton Idle]

Yeah. We just ran ktlintFormat on the entire codebase in a single PR. and then enforced it for the entire codebase. rules that couldn't be autofixed, we skip