Dockerfile Templates

Dockerfile templates live in resources/com/meesho/. Each build stage calls constructTemplate.renderTemplate() to select and render the appropriate template with service-specific values.

TL;DR

Templates use Groovy's SimpleTemplateEngine — ${} substitutions from a Map binding.
constructTemplate.renderTemplate(binding, templateFile, outputPath) calls libraryResource to load the template, renders it, and writes the output file.
Template selection is by dockerBuildVersion string: maven-21, go-1.22, node-20, etc.
Output is always written to the workspace and then used by the Docker build step.
_construct() is annotated @NonCPS because SimpleTemplateEngine is not CPS-serializable.

Mental model

constructTemplate is a thin wrapper around Groovy's standard template engine. The binding map contains all deployment metadata (repo name, version tag, environment, JVM flags, etc.) assembled by the build stage and enable_backward_compatibility(). The template file itself is stored as a Jenkins library resource and loaded via libraryResource.

Structure / data flow

Dockerfile template selection (in each build stage):
  dockerBuildVersion = "go-1.22"
          │
          ▼
constructTemplate.renderTemplate(
  binding = { repo_name, tag, env, ... },
  templateFile = "go-1.22-Dockerfile",   (or "go-Dockerfile" depending on version)
  outputPath = "${WORKSPACE}/Dockerfile"
)
          │
          ▼
libraryResource "com/meesho/go-1.22-Dockerfile"
          │
          ▼
SimpleTemplateEngine.createTemplate(text).make(binding)
          │
          ▼
writeFile(Dockerfile)  →  docker build -f Dockerfile -t <registry>/<repo>:<tag> .

Available templates (from resources/com/meesho/):

maven-Dockerfile          maven-21-Dockerfile
go-Dockerfile             go-1.22-Dockerfile
node-Dockerfile           node-18-Dockerfile    node-20-Dockerfile
python-Dockerfile         python-3.7-Dockerfile python-3.10-Dockerfile python-3.12-Dockerfile
rust-Dockerfile
php-Dockerfile
argoApp.yaml              (ArgoCD Application manifest template)
values.yaml               node-values.yaml      go-values.yaml        python-values.yaml
cron-values.yaml          php-values.yaml

Key code locations

Symbol	File	What it does
`renderTemplate`	`src/com/meesho/utilities/constructTemplate.groovy:renderTemplate`	Loads library resource + renders + writes file
`_construct`	`src/com/meesho/utilities/constructTemplate.groovy:_construct`	`@NonCPS` template rendering via SimpleTemplateEngine
`get_value_yaml_file`	`src/com/meesho/stages/deployArgoCD.groovy:get_value_yaml_file`	Selects which values.yaml template to use for Helm
`get_default_command`	`src/com/meesho/stages/deployArgoCD.groovy:get_default_command`	Default container command per build version

Sharp edges

_construct is @NonCPS (src/com/meesho/utilities/constructTemplate.groovy:_construct): this means it cannot access Jenkins pipeline steps (e.g., echo, sh) or env.* inside the method. All values must be in the binding map. Any caller that invokes _construct inside a parallel block or closure must ensure the closure itself is also @NonCPS or does not cross a serialisation boundary. Do not move _construct into a CPS context — keep the annotation and call it from a CPS-safe wrapper.
binding is copied defensively: _construct wraps the incoming map in new HashMap(binding) before passing to the engine, preventing mutation of the caller's map.
argoApp.yaml is also a template: the ArgoCD Application manifest is rendered the same way as Dockerfiles. This means ArgoCD app metadata (cluster, namespace, Helm chart path) is all driven by the deployment YAML binding.
Values templates select by dockerBuildVersion: get_value_yaml_file maps node-* → node-values.yaml, python-* → python-values.yaml, etc. An unrecognized version returns null and the pipeline fails.

Language builds — which stage calls renderTemplate
Deploy ArgoCD — uses renderTemplate for both ArgoCD app and Helm values

Notes

← Previous · Index · Next →

4.6 KiB Raw Blame History