added files

This commit is contained in:
Your Name
2026-08-26 02:02:24 +05:30
parent 58ee8a276a
commit 3419cfba0c
200 changed files with 22132 additions and 0 deletions
+86
View File
@@ -0,0 +1,86 @@
<!-- m-wiki: type=top-level slug=architecture topic=null base-sha=28f54cf7bef9 generated-at=2026-05-12T00:00:00+00:00 sources=[] -->
> Generated 2026-05-12 at base-sha 28f54cf7bef9. Type: top-level. 0 sources.
# Architecture
devops-lib is a Jenkins Shared Library that implements the entire CI/CD pipeline for all Meesho microservices. Consumer services load it via `@Library('devops-lib@main')` and delegate their full builddeploynotify lifecycle to it through a single `eksCICD(repo)` call.
## TL;DR
- One entry point (`vars/eksCICD.groovy`) routes to GCP (pod-based) or AWS (EKS node) infra via `CLOUD_PROVIDER`.
- A sequential flow: checkout → config parse → build stage → ArgoCD deploy → Ringmaster/Turbo-Turtle notify.
- Language-specific build logic lives in `src/com/meesho/stages/build*.groovy`; infra and policy env vars in `src/com/meesho/utilities/constructParam.groovy`.
- All deployments go through ArgoCD; no `kubectl apply` ever runs directly.
- Secrets and whitelists are injected at runtime — never hard-coded.
## Mental model
Think of `eksCICD` as a dispatcher: it doesn't contain any build or deploy logic itself. It (1) authenticates the triggering user, (2) selects the right infrastructure pod or node, and (3) hands off to `commonCICDFlow`, which assembles and runs the actual pipeline stages in sequence.
Each stage is a separate Groovy class with a `run(Map config)` method. `constructParam.run()` populates `env.*` variables (registry URL, vault endpoint, ArgoCD credentials, etc.) so every downstream stage can read a consistent environment without reconfiguring itself.
## Structure / data flow
```
Consumer Jenkinsfile
└─ @Library('devops-lib@main') → eksCICD(repo)
├─ [auth guard] allowedUsers check
├─ CLOUD_PROVIDER=GCP → gcpInfra() → podTemplate(INFRA_ENV-pod.yaml) → node(POD_LABEL)
│ └─ container('devops-tools') → commonCICDFlow(repo)
└─ CLOUD_PROVIDER=AWS → awsInfra() → node('EKS') → commonCICDFlow(repo)
commonCICDFlow(repo)
├─ checkOut.run(repo) ← clone service + submodules
├─ getYamlParameter.getParam() ← parse config.yaml
├─ buildObjHelper.run(build_tool) ← dispatch to language builder
├─ constructParam.run(param) ← resolve env.* vars
├─ hotFix.run(repo_name) ← skip tests/sonar on hotfix/*
└─ buildObj.run(param) ← build + deploy + notify
├─ build (Maven/Go/Node/…)
├─ deployArgoCD.run()
└─ notify.run() → deployRingmaster.run()
```
## Key code locations
| Symbol | File | What it does |
|--------|------|--------------|
| `call` | `vars/eksCICD.groovy:call` | Top-level entry — auth guard + infra routing |
| `gcpInfra` | `vars/eksCICD.groovy:gcpInfra` | Loads pod YAML from `resources/org/meesho/` and wraps in `podTemplate` |
| `awsInfra` | `vars/eksCICD.groovy:awsInfra` | Runs on static EKS node labelled `EKS` |
| `commonCICDFlow` | `vars/eksCICD.groovy:commonCICDFlow` | Orchestrates the full stage sequence |
| `run` | `src/com/meesho/stages/buildObjHelper.groovy:run` | Dispatches to language builder by `build_tool` |
| `run` | `src/com/meesho/utilities/constructParam.groovy:run` | Sets all `env.*` vars for build + deploy |
| `run` | `src/com/meesho/stages/deployArgoCD.groovy:run` | 4-step ArgoCD deploy per deployable |
| `run` | `src/com/meesho/stages/notify.groovy:run` | Slack + Ringmaster/Turbo-Turtle callback |
## Sharp edges
- **Authorization is strict**: only `ringmaster-bot`, `turbo-turtle`, and the `allowedUsers` list can trigger builds. Builds not in this list are rejected immediately with a message directing to Ringmaster.
- **`env.*` mutation is CPS-bound**: `constructParam.run()` sets `env.*` in a CPS method. Any utility that needs `@NonCPS` cannot read from `env.*` inside the annotation — use method parameters instead.
- **GCP vs AWS env diverge**: `constructParam.run()` has two separate `accountDetails` maps for GCP and AWS. Registry URL, bucket name, and ArgoCD cluster coordinates differ between clouds.
- **`useSidecar` flag**: services that need a sidecar container can pass `useSidecar: true` in the repo Map. This switches the pod template from `INFRA_ENV-pod.yaml` to `INFRA_ENV-sidecar-pod.yaml`.
## Related concepts
- [Build dispatch](build/build-dispatch.md) — how `buildObjHelper` matches `build_tool` strings
- [Environment mapping](05-ENVIRONMENT-MAPPING.md) — branch/PR → `cicd_environment` table
- [Config policy](06-CONFIG-POLICY.md) — `constructParam` env resolution + whitelist gates
- [Deploy ArgoCD](04-DEPLOY-ARGOCD.md) — 4-step deploy sequence
- [Infra pods](09-INFRA-PODS.md) — GCP pod spec selection
- [ADR index](adr/adr-index.md) — the "why" behind devops-lib's core design decisions
- [Security overview](security/security-overview.md) — trust boundaries and credential handling
## Notes
<!-- Anything below is human-owned. wiki-init never reads or modifies content under this heading. -->
---
[← Previous](01-ARCHITECTURE.md) · [Index](../index.md) · [Next →](02-ENTRYPOINTS.md)