Files
devops-lib-gcp/docs/wiki/pages/01-overview.md
T
2026-08-26 02:02:24 +05:30

58 lines
3.9 KiB
Markdown

<!-- m-wiki: type=top-level slug=overview topic=null base-sha=5399a5ddc36b generated-at=2026-05-21 sources=[code:README.md, code:vars/buildPipeline.groovy, code:src/com/meesho/stages/buildObjHelper.groovy, code:resources/com/meesho/config.yaml] -->
> Generated 2026-05-21 at base-sha 5399a5ddc36b. Type: top-level. 4 sources.
# Overview
**devops-lib** is the Jenkins shared library backing every Meesho service's CI/CD pipeline. Service repos import it via `@Library('devops-lib') _` at the top of their `Jenkinsfile`, then call one of the `vars/` globals (most commonly `buildPipeline { ... }` or `eksCICD { ... }`).
It is **not** a service, has no `Dockerfile`, no `Makefile`, no test suite, no local run command. The only "runtime" is Jenkins itself: a Jenkins controller loads the library, evaluates the Jenkinsfile, and executes stages on a pod template selected by `env.INFRA_ENV`.
## How a service repo consumes it
```groovy
// <service-repo>/Jenkinsfile
@Library('devops-lib') _
buildPipeline {
repo_name = 'order-service'
build_tool = 'maven' // or 'go', 'node', 'python', 'gradle', 'docker', 'php'
maintainer = 'roshan.v' // Slack handle for #ci-cd-status mentions
skip_test = false
skip_sonar = false
push_to_jfrog = false // default-branch-only push otherwise
deployArgo = true
}
```
The map flows into [`vars/buildPipeline.groovy`](../../../vars/buildPipeline.groovy) which:
1. Pins to `node('slave02')` ([line 16](../../../vars/buildPipeline.groovy)).
2. Sets `env.msg = 'Job Passed'` and wraps everything in `ansiColor` + `timestamps`.
3. Calls `checkOut``buildObjHelper.run(param.build_tool)` → the selected stage class's `run(param)``notify`.
## What lives where
| Path | Contains | Read by |
|---|---|---|
| [`vars/`](../../../vars/) | 10 entry-point Groovy scripts — the "public API" | Service Jenkinsfiles |
| [`src/com/meesho/stages/`](../../../src/com/meesho/stages/) | 19 stage classes (build, deploy, notify, scan) | `vars/` entry points |
| [`src/com/meesho/utilities/`](../../../src/com/meesho/utilities/) | 8 helpers — `constructParam`, `gitActions`, `nodePoolSelection`, `constructTemplate`, etc. | Stages |
| [`resources/com/meesho/`](../../../resources/com/meesho/) | Per-language Dockerfile + values.yaml + deployment.yaml; the Python validator | Stages (rendered into the service workspace) |
| [`resources/org/meesho/`](../../../resources/org/meesho/) | `{dev,stg,prd}-pod.yaml` Jenkins agent pod templates | `vars/` (via `libraryResource`) |
## Why "no local build / no test suite"
This is a Groovy library loaded by Jenkins, not a JVM app. There is no `build.gradle`, no `pom.xml`, no `package.json` at the repo root — Jenkins discovers `vars/` and `src/` by convention. The only way to "test" a change is to push the branch and point a Jenkins job at `@Library('devops-lib@<branch>')`.
`BUGS_AND_IMPROVEMENTS_REPORT.md` flags the absent test suite as a P0 gap.
## Critical conventions to know before changing anything
- `vars/` files are the public API. Renaming or removing a global is a breaking change for every service Jenkinsfile in the org.
- The `build_tool` switch is in [`src/com/meesho/stages/buildObjHelper.groovy`](../../../src/com/meesho/stages/buildObjHelper.groovy). Unknown values fall through to `defaultBuild` silently.
- The deploy step order (`update_argo_repo``refresh_app_of_apps``update_helm_repo``refresh_and_sync`) is load-bearing — see [04-deploy-flow](04-deploy-flow.md).
- `constructTemplate._construct()` is `@NonCPS` ([constructTemplate.groovy:13-20](../../../src/com/meesho/utilities/constructTemplate.groovy)) — do not call it across a `parallel` boundary.
See also: [02-entry-points](02-entry-points.md), [03-build-dispatch](03-build-dispatch.md), [04-deploy-flow](04-deploy-flow.md), [05-cross-cutting](05-cross-cutting.md), [`docs/tribal-knowledge.md`](../../tribal-knowledge.md), [`docs/acronyms.md`](../../acronyms.md).