support multiple runtimes in quickstarter jenkins agents

[stitakis]

Problem background Currently each jenkins agent provides a runtime version for a specific programming languages. This brings some limitations when upgrading projects from one ODS version to a new one for these cases. If a jenkins agent provides a new runtime version, the project upgrading needs to upgrade to this new runtime version. If there are breaking changes in the new runtime the project migration could take longer than expected and block the migration to the latest ODS version.

Goals for Quickstarters and Jenkins Agents in OpenDevStack

• Easily bring applications using old versions of ODS to its latest version
• Provide a choice around the build/runtime versions (e.g. JDK 11 + 17 + ...)

Challenges

• Hard dependency on SonarQube. The Jenkins base Agent contains a specific version of the SonarQube Scanner CLI which needs to be compatible with the SonarQube service that comes with the latest version of ODS. If versions are not compatible, the SQ integration will break.

Solution?

• Build dependencies and runtime dependencies are always contained in Jenkins Agents
• Every new agent includes the build/runtime versions of the previous agents + a version of the SonarQube Scanner CLI that is compatible with the SonarQube service's particular version. Reason: allow application teams to use the latest version of ODS and not miss their favorite version of a particular Quickstarter technology.
• With each new ODS version, existing Jenkins Agents need to be rebuilt. Reason: ensure continued service with SonarQube and avoid incompatible versions between Scanner CLI and service.

[renedupont]

IMO if there is a new sonar scanner cli version required in the base agent, there is no way to avoid doing

• With each new ODS version, existing Jenkins Agents need to be rebuilt. Reason: ensure continued service with SonarQube and avoid incompatible versions between Scanner CLI and service.

anyway, therefore the challenge:

Challenges

• Hard dependency on SonarQube. The Jenkins base Agent contains a specific version of the SonarQube Scanner CLI which needs to be compatible with the SonarQube service that comes with the latest version of ODS. If versions are not compatible, the SQ integration will break.

is not really an issue here? As soon as a new sonarqube instance version is being deployed that requires a new sonar scanner cli version as well, all agents that are still being used, no matter what version need to be updated and rebuild in order to continue to work. Or am I missing something?

@metmajer Or do you also envision to have several sonar-scanner-cli versions in the base-agent in case more than one sonarqube instances (with different versions) are being used?

[metmajer]

@stitakis @renedupont I missed out on this issue. Thanks for creating it based on the discussion we had in December!

The background for the discussion was to avoid that literally everyone needs to take immediate action when a new version of ODS has been shipped. The hard SonarQube dependency: "a server version upgrade affects every Jenkins Agent whose included sonar-scanner-cli version needs to be compatible" is still somewhat of an annoyance to allow users of an older ODS version to keep using their existing Jenkins Agent images.

Multiple cli versions likely won't solve the problem since only the most recent ones might go well with an update server version. Therefore there seems no way around a rebuild of every existing Jenkins agent. Brais, @renedupont, @stitakis and @gerardcl what do you think?

[renedupont]

With the current setup of having everything needed for a build in one agent-image, I don't see another way to deal with this than updating the agent-base (+rebuilding all inheriting agents) of every ODS (agent-image) version that is still in use once we upgrade sonarqube server instance.

I think the same is potentially true for every other external platform service we use during the build, like Aqua.

[BraisVQ]

Java agent already support multiple runtimes (11 and 17, soon 21 also) so this issue can be closed