I'm aiming to cut M2 today
# kotest-contributors
s
I'm aiming to cut M2 today
a
I'm taking a look at the new Gradle plugin, and I'd like to make some fixes. How long is left before you make the M2 release?
s
I can wait, I can do it later tonight, I'm on central time, so probably well after you've gone to bed
a
haha it's a good thing I find time pressure motivating today
s
lol you got ages, its 13:14 here
a
yeah, but it's not long before my bedtime!
s
ah 🙂
a
so, I'm looking at the test discovery code in TestClassDetector. It will only work for JVM. Is there something else that will work with other targets?
s
that's my next job
I'll be working on native, the kotlin compiler just makes a binary we invoke, guess we'll do the same
android support now works properly, I need to clean it up a little bit, I don't like the hacky way we add the tmp/test-classes path to the runtime classpath
and we don't support AARs but I assume junit doesn't either
if you want to test this from intellij, build the latest intellij plugin from source and install it. Then you can run an individual test using the kotest gradle plugin.
a
ah okay, thanks
I'm tackling the test discovery now, breaking it up into more discrete steps
s
ok cool, as long as we pass a list of FQNs to the launcher using --candidates then the engine won't care what you change
👍 1
a
in Gradle it's forbidden to use Project in a task action, so we'll have to extract the data to our own type
s
gotcha
Forbidden as in will break or just they don't want you to because its deprecated?
a
currently it's deprecated, but when Configuration Cache is enabled it breaks
s
got it
a
and they're going to make CC enabled by default soon...
s
I see gradle 8.12.1 is out now too
I see this a lot too, assume that's not us but just that validate script ?
a
yeah I'm pretty sure that's the Gradle GitHub action. The last time I looked they made a tonne of network calls without caching, and it regularly trips some rate limit
s
ahh
a
for KMP test discovery it'd be nice to have it as a JVM application, that can be invoked from the command line via options. That way the Gradle plugin wouldn't need extra dependencies, and could be very small and slim, and purely focused on configuration.
s
I'll think about how we can do that. For native, perhaps the compiler plugin can generate a giant main() method with all the tests, and then we just invoke that from gradle (if gradle allows us to invoke any old process)