<!-- 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).