jenkins-docker-slave-images

These are docker images created to use as a jenkins slave

How the Build flow works

├───.github
│   └───workflows
│            ├───build-publish-jdk11-dind-image.yaml
│            ├───build-publish-jdk11-tf-deploy-image.yaml
│            ├───build-publish-jdk17-dind-image.yaml
│            ├───build-publish-jdk17-tf-deploy-image.yaml
│            ├───build-publish-jdk21-dind-image.yaml
│            └───build-publish-jdk21-tf-deploy-image.yaml
├───jdk-11
│   ├───dind
│   └───tf-deploy
├───jdk-17
│   ├───dind
│   └───tf-deploy
└───jdk-21
    ├───dind
    └───tf-deploy

• Build and push to Dockerhub will be taken care by docker/build-push-action

• Authentication to Dockerhub will be taken care by docker/login-action

• Image scanning is carried by using trivy

• The builds are scheduled which means they will be triggered at the configured time.

• Each time the build is triggered, 2 versions of image are pushed (also multi arch images)

• One image version will be latest as usual and other will be in a format <image name: <software component 1 short name>_<softwarefersion>_<software component 1 short name>_<softwarefersion>>

  • Eg: dockerofkrishnadhas/jenkins-slave-tf-deploy-jdk17-image:tf_v1.9.1_az_2.61.0

    • This means dockerofkrishnadhas/jenkins-slave-tf-deploy-jdk17-image has terraform 1.9.1 version and azure cli 2.61.0 version

• These are set as cron to be executed monthly once on 17th of every month

• get_software_versions.sh ➡️ This script executes and get the live software versions available in image and passes them as an environment variable in github workflow.