Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LintTask doesn't rerun when editorconfig changes #233

Closed
joshmsamuels opened this issue Jan 17, 2022 · 5 comments · Fixed by #246
Closed

LintTask doesn't rerun when editorconfig changes #233

joshmsamuels opened this issue Jan 17, 2022 · 5 comments · Fixed by #246

Comments

@joshmsamuels
Copy link

joshmsamuels commented Jan 17, 2022

I have been trying to configure kotlinter with my .editorconfig and I was having problems getting kotlinter to respect my rules since it looks like the lint task is being persistently cached.

Every time I make a .editorconfig change and run build, the change gets picked up by kotlinter, however, every time I run LintTask, whether right after a gradle clean or with ./gradlew clean lintKotlin it says there are no issues even though there are lint errors since I changed the editorconfig rules.

As a temporary work-around, #112 (comment) helped me prevent the ListTask from caching when I run ./gradlew lintKotlin --rerun-tasks.

This issue makes me lose confidence in the prePushHook or other linter automation since I will never know if the linter truly should have succeeded, so are there any permanent solutions to this issue?

@mateuszkwiecinski
Copy link
Collaborator

mateuszkwiecinski commented Jan 18, 2022

It seems like the plugin should declare .editorconfigs picked by ktlint as each task's @Input (similairly as ktlint-gradle does - link).
I wonder if it can be done in a smart way using one of the ktlint classes, to make sure the new task input is kept in sync with ktlint 🤔 I'm looking at EditorConfigLoader but I don't quite get where do they search for .editorconfig files location 🤔

@joshmsamuels As a temp workaround I can suggest you to add your .editorconfig file as kotlinter tasks input

    val editorconfigFile = rootProject.file(".editorconfig") // or whatever the file location is.
    tasks.withType<LintTask> {
        inputs.file(editorconfigFile).withPathSensitivity(PathSensitivity.RELATIVE)
    }

@joshmsamuels
Copy link
Author

That worked 🎉 Thank you so much!

Is there a way to define this for all kotlinter tasks instead of just the lint task? It looks like I have to copy the same function for the FormatTask as well

@mateuszkwiecinski
Copy link
Collaborator

mateuszkwiecinski commented Jan 18, 2022

I think we can keep the issue open, as that's still a bug in the plugin and should be fixed at some point 👀

Is there a way to define this for all kotlinter tasks instead of just the lint task?

I don't think you have to define such patch for FormatKotlin task. It is never considered UP-TO-DATE - source, so it will always be executed against most recent .editorConfig* 👀 (of course I might be wrong here, I haven't tested it)

* - Unless you use Configuration Cache, but I'm guessing you don't

@joshmsamuels joshmsamuels reopened this Jan 18, 2022
@jeremymailen jeremymailen changed the title LintTask caching never clears LintTask doesn't rerun when editorconfig changes Jan 19, 2022
@jeremymailen
Copy link
Owner

Yes, as @mateuszkwiecinski points out, the gap here is that editorconfig is not currently an Input to the LintTask, so you have to force a rerun if you change the rules there. Incremental build should behave correctly in all other cases. I changed the issue title accordingly.

It would be nice to resolve the path to editorconfig and use it as an input in the plugin. Currently the resolution and reading of editorconfig is delegated to the underlying ktlint library.

Yes, FormatTask does not attempt to be incremental. If memory serves, doing so would make it unpredictable because sometimes it changes the input files themselves and sometimes it does not.

@joshmsamuels
Copy link
Author

Thanks for the clarification! I also have a shared exclude between the two tasks so if there is a common place I could define that, it would great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants