build: Add Gradle task to assemble module build harness

[skaldarnar]

Contains

Trying to make some Jenkins magic 🪄 more explicit in producing a build artifact for the module build harness that we could publish somewhere and use it in module builds again.

Context

Info is taken from

https://github.com/MovingBlocks/ModuleJteConfig/blob/b8599916257184f1258da5ff209e9fb55c26863f/Jenkinsfile#L62-L63

and

Terasology/Jenkinsfile

Lines 55 to 65 in 43a7e05

	archiveArtifacts '''
	gradlew,
	gradle/wrapper/*,
	templates/build.gradle,
	templates/module.logback-test.xml,
	config/**,
	facades/PC/build/distributions/Terasology.zip,
	engine/build/resources/main/org/terasology/engine/version/versionInfo.properties,
	natives/**,
	build-logic/src/**,
	build-logic/*.kts

How to Test

Module Build

For local testing, run the following in the engine repo, which should produce build/distributions/build-harness.zip.

./gradlew assembleBuildHarness

In a stand-alone checkout of a module (any module should work) extract the build-harness.zip file and try to run the Gradle build. For instance:

# in stand-alone module checkout
unzip ../Terasology/build/distributions/build-harness.zip 

# set project name and include plugin, see https://github.com/MovingBlocks/ModuleJteConfig/blob/b8599916257184f1258da5ff209e9fb55c26863f/Jenkinsfile#L62-L63
echo "rootProject.name = '$(basename "$PWD")'; includeBuild('build-logic');" > settings.gradle

./gradlew build

Engine Build

The config should be extracted as before in the engine. To test this, clean the config/ directory, then run one of the affected tasks and observe that :extractConfig is part of the dependencies and the configs are extracted properly.

For instance, you can run

git clean -fdx -- config
./gradlew checkstyleMain

Follow-up

• build the module build harness in CI and archive the ZIP file in the Jenkins job
• adjust the module build file to use the single build harness archive instead of copying files together
• version the build harness properly and publish to artifactory (and consume from there)
• (optional) implement a Github action to fetch the build harness from artifactory and build modules standalone
• (optional) address the FIXME by revisiting the gradle plugins, how they are structured, what they depend on, etc.

[skaldarnar]

Tried in a Codespace, not working yet 😔

$ ./gradlew build

> Configure project :build-logic
This version of Gradle expects version '4.0.14' of the `kotlin-dsl` plugin but version '4.1.0' has been applied to project ':build-logic'. Let Gradle control the version of `kotlin-dsl` by removing any explicit `kotlin-dsl` version constraints from your build logic.
WARNING: Unsupported Kotlin plugin version.
The `embedded-kotlin` and `kotlin-dsl` plugins rely on features of Kotlin `1.8.20` that might work differently than in the requested version `1.9.0`.

FAILURE: Build failed with an exception.

* Where:
Build file '/workspaces/Health/build.gradle' line: 25

* What went wrong:
An exception occurred applying plugin request [id: 'terasology-module']
> Failed to apply plugin 'terasology-metrics'.
   > Task with path ':extractConfig' not found in root project 'Health'.

[skaldarnar]

Okay,this failing locally is not a problem of the harness assembled here, but it also fails with current develop for module builds, see for instance Modules > H > Health#2.

Edit: The issue was introduced with the Gradle upgrade, 43a7e0 to be precise.

[skaldarnar]

d1d59db should be a workaround for both #5137 (comment) and the failing builds for modules we have right now.

Thus, I propose to get this merged and then address the follow-ups as mentioned in OP.

[jdrueckert]

LGTM