We would still lack the effect of running tests in rendering on commons and platform on rendering and commons. But it’s not critical IMO, and we have that with the clover job that I’m trying to fix (and that we can execute once per week or less).
FTR I’ve computed the total coverage with clover, and got:
14 Sep 2024:
- Commons: 72.3%
- Commons+Rendering: 78.9%
- Commons+Rendering+Platform: 76.2%
Not bad, to be compared with https://dev.xwiki.org/xwiki/bin/view/Community/Testing/TestCoverage/#HExampleReports
The report is available (README).
I’m against this, this will further slow down our build and will make the CI completely useless. We should try to speed up our builds, not make them slower.
I think that’s a bad idea as it means we won’t notice JavaDoc (syntax) errors in those modules anymore that can fail the release. These profiles don’t add much overhead to the TestRelease build as the actual test execution is skipped and therefore this won’t compensate for the additional build time in the quality build.
This is not a profile defined in a pom file that someone would use locally. It’s a specific CI profile defined in the settings.xml of the agents and is here to make sure to build only with the XWiki snapshot repository (and Maven central). It’s used mainly to make sure xwiki-commons and xwiki-rendering do not depend on anything coming from externals or any other non Maven Central repository proxied by nexus.xwiki.org.
I’m also not a huge fan of executing integration tests twice in a build. It would only make sense if we stop building them in the Main build (but maybe that’s the one you had in mind and copy/pasted “TestRelease” by mistake @vmassol ?). Also, are you sure that all it takes to catch integration coverage is to enable them? What we want to cover is running on a different JVM (the XWiki instance JVM).