JDK tools of all LTS versions on all permanent agents of the RelEng JIPP

[HannesWell]

Install the adoptopenjdk Plug-in for the RelEng JIPP and configure it to act as fall-back temurin-jdk tool installer for the Java LTS versions 8, 11, 17, 21 and 25 as requested in:

• https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/7495

This is just an idea/concept proposal how I hope it could maybe work, but I have no experience if it really works and cannot verify it.

I also don't know how well this works in conjunction with the existing temurin-jdk definitions in tools-jdk.hbs:

jiro/templates/jenkins/partials/tools-jdk.hbs

Lines 91 to 108 in 16d90b8

	- name: "temurin-jdk25-latest"
	home: "/opt/tools/java/temurin/jdk-25/latest"
	- name: "temurin-jdk24-latest"
	home: "/opt/tools/java/temurin/jdk-24/latest"
	- name: "temurin-jdk23-latest"
	home: "/opt/tools/java/temurin/jdk-23/latest"
	- name: "temurin-jdk22-latest"
	home: "/opt/tools/java/temurin/jdk-22/latest"
	- name: "temurin-jdk21-latest"
	home: "/opt/tools/java/temurin/jdk-21/latest"
	- name: "temurin-jdk20-latest"
	home: "/opt/tools/java/temurin/jdk-20/latest"
	- name: "temurin-jdk17-latest"
	home: "/opt/tools/java/temurin/jdk-17/latest"
	- name: "temurin-jdk11-latest"
	home: "/opt/tools/java/temurin/jdk-11/latest"
	- name: "temurin-jdk8-latest"
	home: "/opt/tools/java/temurin/jdk-8/latest"

My assumption/hope is, that this overrides only the jdk-tools with the exact same name.
Furthermore I assume only if a new LTS version is released that we want to use on all agents in the RelEng JIPP we have to extend the list of tools defined in the RelEng's configuration.yml.

For continues updates of the defined adoptopenjdk jdk tools, i.e. to new builds of the same major version, one just has to update the corresponding exact label.
But I'm contemplating to suggest/contribute the ability to have a corresponding latest label for each major version to the adoptopenj plugin.

Since I assume that the tools definition is global for the entire RelEng JIPP, I assume we have to add a label like jdk-provider to the provided default agents at:

• https://github.com/eclipse-cbi/jiro-agents/blob/e65111b89f27d2eea8664bda5c00be3f6831c63a/agents.jsonnet#L15
• https://github.com/eclipse-cbi/jiro-agents/blob/e65111b89f27d2eea8664bda5c00be3f6831c63a/agents.jsonnet#L28
• https://github.com/eclipse-cbi/jiro-agents/blob/e65111b89f27d2eea8664bda5c00be3f6831c63a/agents.jsonnet#L41

Or would it be possible to 'inject' the jdk-tool spec using adoptopenjdk only for the permanent agents defined here from one central location? Maybe using a dedicated hbs file? I'm not so familiar with all the configuration languages involved here and therefore can't tell in detail what's possible.
Then the entire fallback mechanism would not be necessary.

[HannesWell]

Or would it be possible to 'inject' the jdk-tool spec using adoptopenjdk only for the permanent agents defined here from one central location? Maybe using a dedicated hbs file? I'm not so familiar with all the configuration languages involved here and therefore can't tell in detail what's possible.

After a bit more research I believe this not possible because one cannot use custom tools per permanent node respectively tool installers are only permitted on a global level for the Jenkins controller.
However we could avoid adding extra labels to the default Kubernetes agents by reverting the logic:
Instead all permanent nodes could be labeled as jdk-tool-installer or alike and then adoptOpenJdkInstaller could be used if that label is available, otherwise it would fall back to the hard-coded paths.

[HannesWell]

@heurtematte or @fredg02 can you tell if this could generally work? Specifically if it works enhance respectively change specific entries of the default jdk -> installations list created by the tools-jdk.hbs file through the configuration.yml or maybe a second handlebars file?

However we could avoid adding extra labels to the default Kubernetes agents by reverting the logic:
Instead all permanent nodes could be labeled as jdk-tool-installer or alike and then adoptOpenJdkInstaller could be used if that label is available, otherwise it would fall back to the hard-coded paths.

Generally I assume it's simpler to use that approach? Unless you think it would be interesting for more projects and should be rolled out for all.

[HannesWell]

In an attempt to make this less complex while keeping it powerful with an opaque fallback for the existing temurin-jdk IDs, I've changed this to implement the fallback strategy in the default tools-jdk.hbs file, but only if an instance explicitly opts-in by setting the enableAutmaticTemurinJDKInstallations attribute of the jenkins object to true (which is false by default).

For me this seems to be an approach with manageable complexity (at least I believe to understand that this is doing the right thing), that's at the same time leads to convenient to use jdk tool installations for pipelines.

Since I assume that the tools definition is global for the entire RelEng JIPP, I assume we have to add a label like jdk-provider to the provided default agents at:

* https://github.com/eclipse-cbi/jiro-agents/blob/e65111b89f27d2eea8664bda5c00be3f6831c63a/agents.jsonnet#L15

* https://github.com/eclipse-cbi/jiro-agents/blob/e65111b89f27d2eea8664bda5c00be3f6831c63a/agents.jsonnet#L28

* https://github.com/eclipse-cbi/jiro-agents/blob/e65111b89f27d2eea8664bda5c00be3f6831c63a/agents.jsonnet#L41

From my side, the only missing thing is the addition of these labels and then this would be applicable.
If you are fine with that, I can create corresponding PRs for that.