Very high Gradle sync times on Idea 2021.1

[gmazzo]

Hi there, this plugins seems to be some kind of broken with the latest version of IntellJ Idea 2021.1. Terminal build seems not to be affected.

We have a big backend project with many modules, and if we switch to latest version of the IDE the project's sync becomes pretty much hang (actually it takes about 30 minutes to finish).

Research

After debugging Gradle’s deamon, I find out the problem was this net.serenity-bdd.aggregator which is doing a pretty strange logic by scanning and changing Gradle’s Configuration paths:
https://github.com/serenity-bdd/serenity-gradle-plugin/blob/main/src/main/groovy/net/serenitybdd/plugins/gradle/SerenityPlugin.groovy#L176

That makes the sync process to enter in a loop on Idea 2021.

After removing that plugin, sync times went back into a decent time: 9secs

[wakaleo]

I don't think the Gradle code has changed for quite a while; feel free to have a play and see if you can find anything to propose in a PR though.

[wakaleo]

That code doesn't seem to do anything related to the Gradle configuration - what makes you think there is a loop involved?

[gmazzo]

That code doesn't seem to do anything related to the Gradle configuration - what makes you think there is a loop involved?

Probably it's not. I didn't go deeper on the plugin's logic to be honest. I've just paused the daemon's JVM after 10 minutes of "running" and I've found it was at that specific stacktrace I've shared in the first screenshot.

It'd be nice if you can take a look at it, probably we won't be the only ones having issues as latest Idea is rolling out.

[gmazzo]

This may give you a clue, it seems it's scanning my whole disk for serenity.conf files 🤔

This seems to be the breaking change:

[wakaleo]

Hmmm, yeah, that could be an issue. I think there was a Gradle bug related to the user.dir variable (it should be the user's home directory, not the root directory). That said, it just checks for the presence of a serenity.conf file there, so there shouldn't be a loop I think.

[gmazzo]

Hmmm, yeah, that could be an issue. I think there was a Gradle bug related to the user.dir variable (it should be the user's home directory, not the root directory). That said, it just checks for the presence of a serenity.conf file there, so there shouldn't be a loop I think.

Yes, even if you just look for a file, scanning the whole disk it's an expensive operation. That's why it was taking 30' to finish for us.

Do you think you can do any workaround for this? Shouldn't this "scanning" be done at EXECUTION time instead of CONFIGURATION time?

[wakaleo]

As far as I know, it doesn't scan, it merely checks for the presence of the file in 3 locations.

[gmazzo]

As far as I know, it doesn't scan, it merely checks for the presence of the file in 3 locations.

It is, look at the stackstrace here:

The serenityConfFileInASensibleLocation of PropertiesFileLocalPreferences is calling SearchForFilesWithName.matching(Paths.get(".")... (see the walkFileTree stacks starting from /)

As user.dir (current directory) is returning /, Paths.get(".") will be / also. That will traverse the whole disk.

[ricardorlg-aval]

I have the same problem, It never finishes configuring a project in Intellij, in the terminal everything works, Also I just try with an old version of the plugin, 2.1.0 and there is no problem, @wakaleo has u seen this problem in Intellij last version?

[gmazzo]

If someone is looking for a workaround, we did "fix" this by not applying the plugin if Gradle is run inside Idea context:

if (!System.getProperty('idea.active')?.toBoolean()) {
    apply plugin: 'net.serenity-bdd.aggregator'

} else {
    // FIXME workaround of https://github.com/serenity-bdd/serenity-gradle-plugin/issues/1
    tasks.register("aggregate") {
        doFirst {
            logger.warn("Serenity Aggregator is disabled, check " +
                    "https://github.com/serenity-bdd/serenity-gradle-plugin/issues/1")
        }
    }
}