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.

devwithkrishna/jenkins-docker-slave-images

jenkins-docker-slave-images

How the Build flow works