Streamline I-build test setup

[HannesWell]

Currently the setup of I-build tests is a very convoluted process that involves multiple levels of shell- and ANT-scripts. It's really hard to fully understand the whole setup and I assume nobody does it at the moment.
The starting point is:

eclipse.platform.releng.aggregator/JenkinsJobs/AutomatedTests/I_unit_tests.groovy

Lines 68 to 80 in 0e81c4f

	curl -o getEBuilder.xml https://download.eclipse.org/eclipse/relengScripts/testScripts/bootstrap/getEBuilder.xml
	echo JAVA_HOME: $JAVA_HOME
	echo ANT_HOME: $ANT_HOME
	echo PATH: $PATH
	env 1>envVars.txt 2>&1
	ant -diagnostics 1>antDiagnostics.txt 2>&1
	java -XshowSettings -version 1>javaSettings.txt 2>&1
	ant -f getEBuilder.xml -DbuildId=${buildId} \\
	-Dosgi.os=''' + TEST_CONFIG.os + ' -Dosgi.ws=' + TEST_CONFIG.ws + ' -Dosgi.arch=' + TEST_CONFIG.arch + ''' \\
	-DtestSuite=all

To streamline and simplify this, my suggestion is to replace the entire setup by a single (big) java class that we deploy to download.eclipse.org/eclipse/relengScripts and that is launched as a Single-File Source-Code Programs, possible since Java-11 with JEP-330. If we use Java-22 or later just to run the setup we can even split that in multiple java files, since JEP-458 and launch them directly.

My suggestion is to start with the getEBuilder.xml ANT script and successively move more of the setup into the java class, until nothing is left:
https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/blob/0e81c4f903ec9e7c11bd92e85c106d96237c2341/production/testScripts/bootstrap/getEBuilder.xml

We can even inline the properties files into the (or one of the) java script(s).

The goal would be to have only very few input arguments, mainly just the buildId and the testSuite and optionally the os/ws/arch (we can try to derive that from system-properties).

The advantages of this would be

• everyone of the active developers of Eclipse knows Java very well
  • not everyone knows ANT or the scripting languages for different OS
• it would be very simple to launch locally as one just has to run it as plain Java-application from the IDE or CLI and has to specify the mentioned parameters (or just set them temporarily in code). No more need to set up ANT, etc.
  • Currently it's very difficult to run I-builds locally and at least on my Windows machine I never made it to run.
• It would be easier to debug as the mentioned launch could simply be run in debug mode
• Modern day Java can be really compact when it comes to file-IO (which the setup mainly is), some things are still a bit more verbose to implement in java than in ANT or a shell-script, but some things are even easier.

[akurtakov]

I like the proposed workflow. Only addition from my side would be to question the need for every bit we move. E.g. first question is what is Ebuilder and is it truly still needed?

[HannesWell]

I like the proposed workflow.

Great. :)

Only addition from my side would be to question the need for every bit we move. E.g. first question is what is Ebuilder and is it truly still needed?

The EBuilder is the ANT-script that bootstraps the integration-test execution. It also provides means to get all the resources to launch these tests from another git respository or branch, which allows trying out changes before submitting them to master:

eclipse.platform.releng.aggregator/production/testScripts/bootstrap/getEBuilder.xml

Lines 36 to 57 in 48e22a3

	<condition
	property="gitHost"
	value="${env.GIT_HOST}"
	else="https://github.com/eclipse-platform">
	<isset property="env.GIT_HOST" />
	</condition>
	<property
	name="testConfigurationBranch"
	value="${buildId}"/>
	<property
	name="projectName"
	value="eclipse.platform.releng.aggregator" />
	<property
	name="eScriptLocation"
	value="${projectName}/production/testScripts" />
	<echo message="=== Properties in 'getEBuilder.xml'" />
	<echo message=" WORKSPACE: ${WORKSPACE}" />
	<echo message=" projectName: ${projectName}" />
	<echo message=" eScriptLocation: ${eScriptLocation}" />
	<echo message=" test-configuration source git branch: ${testConfigurationBranch}" />

In general I think it's important to have means to test changes, locally or on the build server before they are on the master. But depending on the eventual form of the script, e.g. if it's really just one file, it could be sufficient to use an alternative (github-raw) URL to in the job.

But this is just the start. I think it's simpler to start at the beginning and work towards the end and drop unneeded elements on the way.