Tests from examples/kotlin-diktat/warn-dir are failing on Windows with diktat 1.1.0

[orchestr7]

Probably we will need to delete all tests and simply test real scenarios on the executable save-cli

[petertrr]

Do you mean WarnDirTest? As I can see from the latest CI run, this is the test that passes on Linux and fails on Windows

Looks like something is broken in ktlint's pattern matching. save-cli runs the following command:

java -jar ktlint --disabled_rules=standard -R diktat.jar  C:\Users\<user>\AppData\Local\Temp\WarnPlugin--1261806134\warn-dir\**\*.kt

which matches no files. I tried to experiment with forward slashes, but no luck. This, however

 java -jar ktlint --disabled_rules=standard --debug -R diktat.jar  C:\Users\<user>\AppData\Local\Temp\WarnPlugin--1261806134\warn-dir\chapter1\*.kt

works as expected.

Also, running tests by relative glob also works:

...\save\examples\kotlin-diktat> java -jar ktlint --disabled_rules=standard --debug -R diktat.jar warn-dir\**\*.kt

[orchestr7]

Only on windows

[petertrr]

I've opened saveourtool/diktat#1397 to investigate root cause and maybe even fix on ktlint's side. I'll disable these tests for now until this issue is resolved

[petertrr]

Actually now that I investigated it a bit, I find behavior of wildCardInDirectoryMode quite confusing. Why, for example, for warn-dir/chapter1 we are passing pattern to the tested tool as warn-dir/**/*.kt instead of warn-dir/chapter1/**/*.kt? Here is the log:

[TRACE]: Discovered the following test resources: [Test(test=../examples/kotlin-diktat/warn-dir/chapter1/EnumValueSnakeCaseTest.kt), Test(test=../examples/kotlin-diktat/warn-dir/chapter1/GenericFunctionTest.kt), Test(test=../examples/kotlin-diktat/warn-dir/chapter1/SmallTest.kt)]
[DEBUG]: Validated plugin configuration for [../examples/kotlin-diktat/warn-dir/chapter1/save.toml] ([WARN])
...
[TRACE]: Constructed file names for execution for warn plugin: C:\Users\<user>\AppData\Local\Temp\WarnPlugin--89925833\warn-dir/**/*.kt
[..
[DEBUG]: Executing: CMD, /C, cd /d ../examples/kotlin-diktat && java -jar ktlint --disabled_rules=standard -R diktat.jar  C:\Users\<user>\AppData\Local\Temp\WarnPlugin--89925833\warn-dir/**/*.kt with timeout 90000 ms

I think we should append wildcard pattern to the root of test suite that is being currently executed.

Edit: this is because of this code:

save-cli/save-common/src/commonMain/kotlin/com/saveourtool/save/core/utils/CmdExecutorBase.kt

Lines 74 to 78 in 1c24995

	var testRootPath = copyPaths[0].parent ?: ".".toPath()
	while (testRootPath.parent != null && testRootPath.parent!!.name != tmpDirName) {
	testRootPath = testRootPath.parent!!
	}
	"$testRootPath${getWildCardInDirectoryMode()}"

Edit 2: this logic even is fixed in this test:

save-cli/save-core/src/commonNonJsTest/kotlin/com/saveourtool/save/core/integration/WarnDirTest.kt

Lines 29 to 35 in 1c24995

	@Test
	fun `execute warn plugin on root directory`() {
	val reporter = runTestsWithDiktat(listOf("warn-dir"), 6)
	reporter.results.forEach { testResult ->
	assertTrue(!testResult.debugInfo!!.execCmd!!.contains("chapter"))
	}
	}

but I can't neither remember nor understand why we implemented it this way :( @akuleshov7, do you remember if it's related to #350?

[orchestr7]

As we discussed:

1. [warn] plugin -> is simply processing separate files
2. [warn] plugin + DIRECTORY flag -> run ONLY on this directory. Plugin uses from one single file with all warnings (no inline warnings). It will make the logic less complex. In this mode (with directory flag) we will ignore other nested save.toml files and detect tests from the file with expected warnings.

We need to create a logic on save-cloud for it also...

[petertrr]

To sum up, tests in save-cli are failing because of some issues with ktlint 0.45.x + diktat 1.1.x, as described in #402 (comment).
Let's create a separate issue for new logic of directory mode.

[kgevorkyan]

Need to check the relevance of the problem, a lot of time have passed, and the versions of used tool were upgraded

[petertrr]

We should try to re-enable tests disabled in #407 and see if they still fail. Otherwise, the problem is indeed resolved.