Disable Configuration Cache in generated pre-commit Gradle call

[pkubowicz]

internalKtlintGitFilter is part of the cache key, and it changes with every commit, so getting a cache hit is extremely unlikely.

If you execute the commit hook (in the form before my changes) with Configuration Cache enabled, you will see:

Calculating task graph as configuration cache cannot be reused because the set of Gradle properties has changed: the value of 'internalKtlintGitFilter' was changed.

[JLLeitschuh]

I'm guessing this is going to fail CI because the PR doesn't update the test testing the the pre-commit script that is generated. Just and FYI.

Thanks for the contribution!

[JLLeitschuh]

Also, this needs a change log entry please!

[pkubowicz]

I added a change log entry.

I also executed GitHookTasksTest and it passed. From what I see inside the test, it does not check the contents character by character, but rather asserts that certain key words (like the task name) appear. Also, the string --quiet only appears in production code, never in test sources.

[pkubowicz]

Something for the future: instead of relying on -P (which does not work well with configuration cache), git filter can be modeled as a CLI option: https://docs.gradle.org/current/userguide/custom_tasks.html#sec:declaring_and_using_command_line_options

So instead of running:

./gradlew --quiet ktlintCheck -PinternalKtlintGitFilter="my-file"

the call will look like this:

./gradlew --quiet ktlintCheck --git-filter="my-file"

with the default for option not passed being **/*.kts,**/*.kt. This would require moving fun BaseKtLintCheckTask.applyGitFilter() away from GitHook.kt (this does not look like the responsibility of the hook code anyway) and closer to Task.action.

[p00j4]

Hi @pkubowicz ,
Thank you for fixing this issue.

Like you indicated, I experienced similar. And yes, now I understand why i'm not getting benefitted from the configuration cache. And so my execution time is hitting 1.2 mins, which is high every push/commit.

Was there any further decision on making it work with the alternate you suggested? --git-filter="my-file" and will it be any faster?

[pkubowicz]

Should I do anything about this PR? I can solve conflicts, but if no one want to merge this, I'll be just wasting my time.

[JLLeitschuh]

@wakingrufus can you review this quickly when you get a chance. You understand this code better than I do

[JLLeitschuh]

Should I do anything about this PR? I can solve conflicts, but if no one want to merge this, I'll be just wasting my time.

Thanks for the ping reminding us about this one. Sorry for not getting back to you about this sooner

[wakingrufus]

@wakingrufus can you review this quickly when you get a chance. You understand this code better than I do

I'll take a look. Give me a little time to dig into this one

[vpelikh]

Hey @wakingrufus - pinging this PR as an interested bystander. Would you mind giving it a review when you get a chance? We'd love to see this move forward. Thanks!

[JLLeitschuh]

@copilot resolve the merge conflicts in this pull request

[JLLeitschuh]

Okay... So copilot doesn't work on pull request from external contributors... Soooo... Conflicts will need to be resolved. Sorry

[pkubowicz]

I already resolved conflicts and pushed.

[JLLeitschuh]

Running the tests