search

opendevstack / ods-quickstarters

Contains project quickstarters (boilerplates) for Nginx, Go, Java (Spring Boot), Python (Flask), Rust (Axum), Scala (Play), TypeScript (Express), Angular, Ionic, Jupyter, RShiny - all including CI/CD integration & Jenkins build agents
Apache License 2.0
29 stars 41 forks source link

support multiple runtimes in quickstarter jenkins agents #694

Closed stitakis closed 10 months ago

stitakis commented 2 years ago

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

Challenges

Solution?

renedupont commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 10 months ago

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