Ktlint spotless tasks are always "up-to-date" even when there are changes #144
Comments
|
Try putting a sleep(2000) in between the two calls to runTestWithHeader(). Also, it would be simpler to assert that the content equals something, rather than startswith, endswith, and contains. |
|
Regardless of the test failing I see the behaviour in my own builds. |
|
Yes, even with the |
|
Well it's great to have a reproducible test case! Adding |
|
Updated test code: @Test
public void testWithHeader() throws IOException, InterruptedException {
write("build.gradle",
"plugins {",
" id 'nebula.kotlin' version '1.0.6'",
" id 'com.diffplug.gradle.spotless'",
"}",
"repositories { mavenCentral() }",
"spotless {",
" kotlin {",
" licenseHeader('" + HEADER + "')",
" ktlint()",
" }",
"}");
// First run, this will put the task into it's "up-to-date" state.
runTestWithHeader();
Thread.sleep(2000);
// Second run should see the changes and the task should not be "up-to-date".
runTestWithHeader();
}
private void runTestWithHeader() throws IOException {
final File testFile = write("src/main/kotlin/test.kt", getTestResource("kotlin/licenseheader/KotlinCodeWithoutHeader.test"));
final String original = read(testFile.toPath());
gradleRunner()
.withArguments("spotlessApply", "--debug")
.forwardOutput()
.build();
final String result = read(testFile.toPath());
Assertions
.assertThat(result)
// Make sure the header gets added.
.startsWith(HEADER)
// Make sure that the rest of the file is still there with nothing removed.
.endsWith(original)
// Make sure that no additional stuff got added to the file.
.isEqualTo(HEADER + '\n' + original);
}Test results: |
We had up-to-date checking in BumpThisNumberIfACustomStepChangesTest. But we missed an important case. Added UpToDateTest which exposes this. Evidence for issue #144, many thanks to @JLLeitschuh for the find.
|
This was an excellent find. We do have have an up-to-date bug, but it's quite hard to trigger, and this test isolated it perfectly. It's not related to ktlint, it's for all our formatters. The sequence to trigger the bug is this:
If you never follow that exact sequence, you'll never see it. And to fix it, all you need to do is add a space or something and you'll be back in the proper pipeline. Surely many users (and authors!) have encountered this, but shrugged it off as a brain fart / editor saving weirdness. I added a commit (just above) which demonstrates this more clearly. Miraculously, I've been working on another gradle plugin with weird up-to-date checking, and I think there's a hack I learned there that can fix this problem. I'll submit a PR with a fix tomorrow.. |
I'm pretty sure I've encountered such behaviour with Spotless myself in the past, not knowing for sure what was causing it. Here's to hoping this resolves that little niggle. 😃 |
|
Although, I find it curious we even need a hack to get this working. Something to report to the Gradle team about? 🤔 |
|
The up-to-date API they have is great for |
|
This is currently in |
|
Published as |
|
Woot!!! :D Thanks for doing a deep dive on this and figuring out what the cause is. Really awesome support from you all. Awesome tool you have here. I'm always pleased with your professional nature. |
|
Thanks for the testcase! |
|
Just FYI, I've posted this and another example to the gradle forum. |
|
I would have posted that as a github issue, but sure. |
I see this issue both with linting Gradle Kotlin DSL files and Kotlin Source files.
Making a change to source code after running spotless and getting a success the task seems to get stuck as always "up-to-date".
A simple example of this is an updated version of the
KotlinExtensionTest::testWithHeaderthat I wrote.The test as it is in master currently passes 🎉 .
However, changing the test so that it looks like this:
Results in this test failure:
You will notice that the failure stack trace is from the second call to
runTestWithHeadermeaning that the second run ofspotlessApplydidn't reformat the source code.The text was updated successfully, but these errors were encountered: