https://gradle.com/ logo
Join SlackCommunities
Powered by
This message was deleted.
# configuration-cache
s
This message was deleted.
v
Why is it ignored? If you use a system property and its value changes, the CC should be invalidated automatically and redo the configuration. Do you maybe have or can knit an MCVE showing your problem?
c
sorry..I think you focused in the wrong part of my question (so I have written it badly) I would like to be able to provide different values to includeCategories while reusing CC. 
./gradlew :whatever:test -DincludeCategories=cat1
and 
./gradlew :whatever:test -DincludeCategories=cat2
but the issue is 
JUnitOptions.includeCategories(String...)
is doesn't accept a Provider, so it requires to be changed in configuration time
changing the set of tests to run, from the same task, should only affect execution time, not configuration.
v
Hm, maybe if you leverage the 
getTestFrameworkProperty
. It is the 
Property
that carries the test framework to use, so you can maybe there make the settings lazily?
šŸ¤” 1
As the actual test frameworks are internal classes, you probably would have to do 
useJUnit()
and then something like 
testFrameworkProperty.set(testFrameworkProperty.map { ... }
or something like that. But I'm not sure whether that will then end up in a circular reference.
c
it's worth a try, thanks!
v
Give an update how it worked out. šŸ™‚ A quick try gave a 
StackOverflowError
due to the circular reference.
c
yeah, I was going to tell you šŸ˜‚ 
java.lang.StackOverflowError
it is
v
Besides that, depending on concrete use-case it might be better to not have the categories dynamic, but have multiple tasks for the different options. Then you can just decide which task to run instead of using some property. That would also allow you to run all tasks in one run instead of multiple runs with different settings and you could also better leverage features like build cache.
c
true, but... ā€¢ it's a big legacy codebase, I would like to improve build times without deeper changes ā€¢ configuration time is one of our biggest issues (1 to 4 minutes) ā€¢ those tests using categories are E2E so the buildCache won't really help
v
Yeah, as I said, always bound to the concrete use-case of course. šŸ™‚
c
with 17 different shards for that E2E test, being able to reuse CC, so save 1-4 minutest per shard, would be a great improvement
v
Indeed
If you cannot solve it from Gradle side, maybe there is some way to not configure the categories using Gradle config, but having some JUnit extension, or environment variable JUnit is evaluating or similar.
For example having a custom JUnit runner that is a subclass of the 
Categories
runner that does not take the categories from an annotation but from somewhere else.
Or 
CategoryFilter
might be what you need to programatically define which categories to include
c
I'm reading all the options you say and googling them a little to see which would be the best solution. Thanks
šŸ‘Œ 1
BTW I tried:
Copy code
tasks.withType(Test).configureEach {testTask ->
    testTask.testFrameworkProperty.set( provider {
        def tf = new JUnitTestFramework(testTask, (DefaultTestFilter) testTask.getFilter())
        Provider<String> includedCategories = providers.systemProperty("includeCategories")
        if (includedCategories.isPresent()) {
            (tf.options as JUnitOptions).includeCategories(includedCategories.get().split(","))
        }
        return tf
    })
}
it seems to work (although I have no tests in there) but then CC is not reused when I change the 
includeCategories
I guess 
testFrameworkProperty
is read during configuration time anyway (I guess it makes sense as changing the framework may affect many things)
v
Hm, yeah, could be that the providers are actually realized before serializing the task state to save as much as possible when reusing configuration cache. Even file collections are realized to actual list of files iirc. šŸ˜•
So you probably indeed need one of the JUnit native methods I mentioned or something similar
šŸ‘ 1
Open in Slack
PreviousNext
Powered by