This message was deleted.

The idea, which seems to work pretty well, is to benefit from the ability of the configuration cache to run tasks in parallel

Not an answer actually, but did you consider using Spocks ability to run tests in parallel instead?

but did you consider using Spocks ability to run tests in parallel instead?

Yes, but that's not the same. AFAIK Spock would run in-process, vs out of process. This could cause potential issues with shared state. Also I would benefit from individual caching of tests and predictive test selection with my technique. But the drawback is that it is also more resource intensitve.

interesting idea, I like the sound of it. I've wondered before if tests could be improved by more tightly integrating with Gradle tasks. The easiest workaround that I can think of is to opt-out of CC for those custom tasks https://docs.gradle.org/current/userguide/configuration_cache.html#config_cache:task_opt_out. I presume the tasks will still run in parallel... For a more 'correct' implementation, but complicated: Use incremental task inputs to get the packages, and for each added/modified package launch the tests in parallel via the Worker API.

AFAIK Spock would run in-process, vs out of process.

That's correct.

This could cause potential issues with shared state.

Of course the tests have to properly support it, yes, or define that they need a specific resource.

Also I would benefit from individual caching of tests

Yeah, that's true of course

and predictive test selection with my technique.

I'm curious, as I'm not working with GE, why does your technique benefit from it and just using Spock parallel support not? Afair it selects individual tests from the whole test suite, not only specific test tasks.

But the drawback is that it is also more resource intensitve.

And more complex to setup and so far not CC compatible. 😄

let's keep this thread on the original topic 🙂

Yeah, right, sorry for the little side-question

It looks like calls to traverse directories are not properly captured as configuration inputs. There have been lots of progress on this in 8.1, it might be worth trying it out and reporting issues if need be.

The idea, which seems to work pretty well, is to benefit from the ability of the configuration cache to run tasks in parallel

Gradle already runs tests in parallel on different JVMs. What is the advantage of using separate tasks per package?

I have complete control on what runs in parallel, and each test task can be cached independently, which is not the case with internal parallel forking

If nothing else, maybe write your traversal out to a file and read it using

TextResource#fileContent

?

indeed this works... not great but it works

A bit late to the party... As Paul said, Gradle 8.1 will have input detection for directory and file collection traversals, but in this case a custom

ValueSource

seems more fitting anyway - it looks like adding a file to an existing directory should not invalidate the configuration, and this is something you won't get with just

listdir

- Gradle has no way of knowing what you're going to do with the listing, so all directory's contents become part of the cache fingerprint. The

ValueSource

only invalidates the cache if its output changes, so you have a chance to ignore irrelevant differences.

a way I can declare the inputs to configuration manually?

ValueSource

is the recommended way to do that.