Mukul Sharma
4b908150e4
Every language's Dockerfile fallback template now pulls from harbor.192.168.1.7.nip.io/base-images/... (mirrored from Docker Hub via the new devops-base-images repo) instead of pulling live from Docker Hub on every build. Eliminates that external dependency at build time, and lets the mirrored tags be deliberately the leanest official variant rather than whatever a public tag happens to default to. - go: unchanged tags (golang:1.22-alpine, alpine:3.20 — already minimal), just re-hosted. - node/python/java: moved from their Debian-slim defaults to the -alpine equivalent (node:20-alpine, python:3.12-alpine, maven:3-eclipse-temurin-21-alpine, eclipse-temurin:21-jre-alpine). - php: bigger change — dropped php:*-apache (Debian, full Apache httpd) entirely for php:*-cli-alpine + PHP's own built-in dev server (`php -S`), moving to port 8080 like every other language instead of PHP's special-cased 80. Not production-grade PHP serving (PHP's own docs call the built-in server not designed for that), but genuinely minimal and fine for a homelab/demo app — would need php-fpm+nginx for anything serving real traffic. Only versions actually mirrored into Harbor resolve now — a dockerBuildVersion whose tag isn't in devops-base-images/images.txt needs that added and re-mirrored first, unlike pulling straight from Docker Hub where any tag "just worked". Chose keeping a shell (Alpine) over full distroless — homelab kubectl-exec debuggability weighed more than the last bit of attack-surface reduction.
devops-lib
Parameters
Most of the functionality depends on the parameters provided by the users in form of groovy map of key and value pairs. The supported parameters are as below:
Required parameters
repo_name: The key repo_name is required for checking out the code in a subdirectory. The value is the repository name that you want to checkout
build_tool: This parameter is required to identify which build_tool to use in the pipeline. The supported values are maven, gradle, docker, python, node, go, php (and their prefixed variants such as maven-3.3-jdk-17, python-3, node-16, go1.21)
maintainer : This parameter is required to send the notification in the slack channel #ci-cd-status. Please provide your slack username here
Optional parameter
devops-lib is Homelab's Jenkins Shared Library that provides a unified CI/CD pipeline for all microservices across the organisation. Consumer repos load it via @Library('devops-lib@main') and call a single eksCICD(repo) entry point — the library handles language-specific building (Maven, Go, Gradle, Node.js, Python, PHP), code quality gates (Sonar), Docker image publishing to GAR/ECR, Helm chart updates, and ArgoCD-based deployment to GKE/EKS clusters. Build status and deployment metadata are reported back to Ringmaster and Slack.
Stack: Groovy (Jenkins Shared Library) · ArgoCD · Helm · GCP (GKE, GAR, GCS, Vault, Sonar) · AWS (EKS, ECR, S3)
Dependencies
push_to_jfrog: By default master, main, gcp-main, and gcp-master branches push artifacts to jfrog/s3 repository, set this parameter to true to push artifacts from non-master branches
config.yaml schema (consumer services)
Every service that uses this library must provide a config.yaml:
| Key | Required | Description |
|---|---|---|
repo_name |
yes | GitHub repo slug — must match exactly |
build_tool |
yes | maven, go, gradle, node-*, python-*, php, docker |
dockerBuildVersion |
yes | Drives Dockerfile template: maven-21, go-1.22, node-20, etc. |
team |
yes | Team slug — validated against buTeamMapping |
bu |
yes | Business unit: supply, demand, central, dataengg, datascience, mcache, infra |
maintainer |
yes | GitHub handle for Slack notifications |
deployment_order |
yes | List of ArgoCD application names to deploy |
notify_channel |
no | Slack channel (default: ci-cd-status) |
skip_sonar |
no | Whitelist-gated; see constructParam.groovy |
deployArgo |
no | Set false to skip ArgoCD sync |
appConfigEnabled |
no | Required true for stg; whitelist-gated |
skip_test |
no | Skip unit tests (Maven) |
push_to_jfrog |
no | Publish JAR to JFrog Artifactory |
push_to_s3 |
no | Push artifact to S3 |
build_packages |
no | System development packages required while compiling (currently consumed by Rust builds; for example libpq-dev) |
runtime_packages |
no | System runtime libraries required by the compiled binary (currently consumed by Rust builds; for example libpq5) |
Adding this library to a new service
// Jenkinsfile
@Library('devops-lib@main') _
eksCICD([
repo_name: 'my-service'
])
Place config.yaml at the repo root with the required fields above.
Adding a new build stage
- Create
src/com/homelab/stages/build<Lang>.groovyimplementingdef run(Map config). - Add a
caseinsrc/com/homelab/stages/buildObjHelper.groovy. - Add a Dockerfile template in
resources/com/homelab/<lang>-Dockerfileif needed.