Giter Site home page Giter Site logo

Comments (5)

cschweikert avatar cschweikert commented on August 10, 2024

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.

from ods-docker-images.

metmajer avatar metmajer commented on August 10, 2024

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

from ods-docker-images.

cschweikert avatar cschweikert commented on August 10, 2024

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?

from ods-docker-images.

cschweikert avatar cschweikert commented on August 10, 2024

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.

from ods-docker-images.

s2oBCN avatar s2oBCN commented on August 10, 2024

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

from ods-docker-images.

Related Issues (1)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.