Structure different versions of images

[cschweikert]

With the Node.js-based agent we had some trouble in the past in regards to naming, tagging etc. I guess we should think about a proper structure that helps with creating and maintaining images with the right tags.

Regarding versioning and tags we have to think about:

• ODS version (e.g. 4.x) for which some image was designed for
• version of some technologie within that image (e.g. different Node.js versions)
• maybe also mixtures of versions, if the image contains different technologies where the version plays a role (e.g. Node.js with a specific browser version)
• tags only for major or also minor versions
• etc.

@s2oBCN @stitakis Is there already a plan for this?

[cschweikert]

BTW Since last week we have version 16 (https://github.com/opendevstack/ods-quickstarters/tree/master/common/jenkins-agents/nodejs16/docker) next to version 12 of the Node.js builder agent and there will be version 18 till end of month (https://nodejs.org/en/about/releases)

Also in the past we were thinking about having a plain Node.js builder agent next to the current agent with its cypress support.

[metmajer]

Adding @jorge-romero and @jafarre-viewnext who are providing Quickstarter consulting to an enterprise

[cschweikert]

On the ODS repos we usually have a branching structure like this:

• branch master: this branch contains the latest development version
• branches 4.x, 3.x, ...: these branches are the development branches starting from a major version release. Things like bugfixes and security updates, but also newest versions of the quickstarters are getting backported from master to those branches
• tags like v4.0.1, v3.0.0, v3.1.0: tag releases within a major version stream

On the example of a plain (without cypress or Chrome) Node.js-based builder agent tagging and versioning of a potential dockerhub image jenkins-agent-nodejs could be organized like this:

• latest, 4, 4.0, 4.0.1, 4-nodejs16, 4-nodejs16.5: asuming 4.0.1 is the latest ODS release and 16.5 is latest Node.js LTS release those tags reference the Node.js version 16.5 agent. The build of the image was done from the release tag v4.0.1 (see above).
• 4.0.0: this image would be build from release tag v4.0.0, etc.
• 4-nodejs12: legacy version of the agent based on Node.js version 12.19 (latest in 12.x). This would be rolling on the same 4.x branch as 4-nodejs16
• 4.0.0-nodejs12: same as 4-nodejs12 but build from release tag v4.0.0

In addition there could be Node.js-based images with additional content, e.g. with cypress support. An image could be named jenkins-agent-nodejs-cypress or so. Maybe we can also name jenkins-agent-nodejs like jenkins-agent-nodejs-base instead to not confuse with the old naming where cypress was included. Versioning and tagging could happen on the same way as for the plain Node.js image above. It might make sense to build the images with cypress support from the respective jenkins-agent-nodejs-base image, e.g. jenkins-agent-nodejs-cypress:4-nodejs16 uses FROM jenkins-agent-nodejs-base:4-nodejs16, etc.

@stitakis @s2oBCN @jorge-romero @jafarre-viewnext First of all does this kind of versioning and tagging make sense to you?

[cschweikert]

Actually the situation on the cypress-side might be more complicated:

• Do we embed cypress itself into the agent so that we can use it without postinstallation (an npm install of cypress usually loads binaries for running on the agent) or do we stick to the bare minimum and just provide the cypress-dependencies on the OS level (e.g. Xvfb) as we do right now? Maybe embeding cypress is not needed since everybody would now be able to build a custom agent based on jenkins-agent-nodejs-cypress (see also https://github.com/opendevstack/ods-quickstarters/blob/master/docs/modules/quickstarters/pages/e2e-cypress.adoc#cypress-without-post-installation).
• cypress also needs a version of Chrome inside the image to run. Do we want to tag different browser versions as well? TBH the practical use of tagging different browser versions is pretty low. The only clear benefit of this would be around the topic of visual regression where the build environment needs to be 100% reproducable. But that would also be the case by pinning a certain image version (e.g. jenkins-agent-nodejs-cypress:4.0.1).

tl;dr

Let's not plan with embedding of cypress binaries and additional tags for browsers here.

[s2oBCN]

Hello Christian, I updated the readme, with the versioning strategy. I think it is flexible enough to get your requirements.

• Now it's publishing the images to my DockerHub repo, but once done, it will publish to the official one (https://hub.docker.com/u/opendevstackorg)
• Also we have to update the names of the images.