Change "setSource", so it also applies the configured filter

[aytchell]

In our project we're using gradle-ktlint plus we have a GraphQL API and generate stubs from a schema file.
We have team members working on Linux, MacOS and Windows.
To exclude the generated code from linting and formatting we've added this filter statement to our build.gradle.kts:

val sep = File.separatorChar
ktlint {
    version.set("0.49.1")
    filter {
        exclude { it.file.path.contains("${sep}generated$sep") }
    }
}

This works fine for our team members using Linux and MacOS.
But the exclude statement is ignored on the Windows machines (which looks a bit like #579 ).

The changes in this PR fix the exclude filter for our team members developing on Windows.

(at the moment we're using version 11.5.0 of the plugin; tests have shown, that with 11.6.0 the filter is still ignored and this patch works, too)

[wakingrufus]

does this mean the filter is applied twice? since the provider on line 120 also applies the same filter?

[aytchell]

Actually this is my first contact with gradle internals so I don't fully understand when these methods are called.
From diffing the debug output of Windows and Linux runs I got the impression, that filesystem changes (inotify et al triggered while generating the stubs) are somehow handled differently.

[wakingrufus]

Thanks for the PR! I have 1 question which I put on the change set itself.

[wakingrufus]

FYI, out github actions run the full test suite on osx, linux, and windows, so you should be able to add a failing test and see it fail on the windows action (since this seems to be a windows-specific issue).

[aytchell]

FYI, out github actions run the full test suite on osx, linux, and windows, so you should be able to add a failing test and see it fail on the windows action (since this seems to be a windows-specific issue).

I feared that request a bit (and at the same time I would've suggested this, too :-D).
I'll try to come up with such a test ...

[wakingrufus]

which gradle version are you using? this might be an issue that was fixed in gradle itself

[aytchell]

I've managed to write a unit test which passes on Linux but fails on Windows.
The unit test has its own commit (514f7e1).
Should I modify this PR (or open another one) so that it only includes the new test? This way we could verify this behaviour with the PR test suite (I've only called ./gradlew build on both OSes)

[aytchell]

In the project we're using gradle 8.3

[wakingrufus]

thanks for the failing test. the thing about your potential fix, is that it shouldnt make a difference. the way apply the patternFilterable to the FileCollection, it is "live". as files are added to the collection, the filter will be applied to those new files. I wonder if maybe the windows failure is happening b/c the file is created too close to when the ktlint task runs, and maybe windows file system is not actually showing the file yet.

[wakingrufus]

can you add that test to this branch so I can run the CI checks on it?

[aytchell]

I've dropped the last commit (with the fix in it) from my remote branch, so the only change is the new unit test.
Once the test suite ran (and "hopefully" failed) I can push the fix onto the branch and you can re-run the test suite

[aytchell]

Hi there, is there anything missing from my side, so the test suite can start? If not: could anyone with the necessary privileges please start the tests?

[aytchell]

I've rebased my branch to the latest main and fixed the finding of ktlint
@wakingrufus Could you please start the test suite?

[JLLeitschuh]

Approving run now. Sorry about the delay

[aytchell]

Ok, this is interesting. The new test fails on my Windows machine.
I'm gonna check if this is somehow timing related