Multi-module projects: aggregated Serenity reports generated in the wrong directory

[patrickvkb]

serenity-cucumber-starter.zip

Description and How To Reproduce

Starting from the serenity-cucumber-starter I created a multi-module project as given in the attached ZIP file. All used version are listed in the root build.gradle:

    dependencies {
        classpath "net.serenity-bdd:serenity-gradle-plugin:4.0.12"
    }

    sourceCompatibility = 17
    targetCompatibility = 17

    ext {
        serenity_version = '4.0.12'
        junit_platform_launcher_version = "1.9.3"
        cucumber_junit_platform_engine_version = "7.14.0"
        junit_platform_suite_version = "1.9.3"
        junit_jupiter_engine_version = "5.10.0"
        junit_vintage_engine_version = "5.10.0"
        logback_classic_version = "1.2.10"
        assertj_core_version = "3.23.1"
    }

Performing then the following shell commands:

cd <root_project_dir>/submodule2
../gradlew clean test

it is seen that the SERENITY-JUNIT-xxxx.xml files are found in the submodule2/target/site/serenity directory but that the aggregate Serenity report was generated in the submodule1/target/site/serenity directory using non-existing xml files there.

Workaround

Using version 3.9.8 of the plugin, all seems to work fine.

Timid Hint to the Possible Cause

During some debugging of the serenity-gradle-plugin, it appeared that the value of the project.build.directory property in the SystemPropertiesConfiguration.environmentVariables always equals the directory of the first submodule. Could not find out as yet how this situation occurs. Help here would be very much appreciated.

[tnielens-centrica]

I did experience similar issues in a multi-module project. In my case, several gradle tasks failed. The issue seemed to be serenity settings from the first submodule applied to the other submodules. I faced similar issues with the plugin version 3.9.8 and 4.0.27.

I think it's related to gradle module parallelism. When I disable parallelism in my gradle.properties file or with the --no-parallelism, I don't reproduce the issues anymore.

[obudilovsky]

@gallardo @wakaleo @patrickvkb @tnielens-centrica --no-parallelism does not help solving it. So please share, how else can you get around this problem?

[tnielens]

What version of the plugin are you using? I think we downgraded to version 3.* to make it work.

[obudilovsky]

group: 'net.serenity-bdd', name: 'serenity-gradle-plugin', version: '4.0.46' group: "net.serenity-bdd", name: "serenity-core", version: '4.0.46'

@tnielens Does it mean that 4. v is broken and forbidden to use it?

[wakaleo]

Downgrading to 3.9.8 means you are using an older version of the library and won't have access to the latest selenium etc. I don't use Gradle, so it would be quicker to dig into the code and propose a PR to fix the issue.

[tnielens]

@wakaleo I'll take a look at this one. Could you move forward with #19 before? It's a large refactoring which I'd like to base the investigation here on.

[tnielens]

Version 4.0.27 of the plugin does not separate configuration and action phases of the different serenity tasks, which #19 addresses.

[tnielens]

I'm running the plugin with revision ba6a994 (current main branch after #19 merge) and don't reproduce the multi modules and parallelism issues described above.