gitadmin/devops-lib-gcp
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

added files

Browse Source
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
Download Patch File Download Diff File Expand all files Collapse all files
docs/skills/README.md
+9
View File
@@ -0,0 +1,9 @@
# devops-lib Skill Proposals
Proposed Claude Code skills for devops-lib. Each proposal targets a specific daily friction point observed from code review patterns, task-replay data, and tribal knowledge gaps.
| Skill | One-line description | Priority | Owner |
|---|---|---|---|
| [`pipeline-tracer`](./pipeline-tracer/SPEC.md) | Given a service config.yaml and branch/trigger context, trace the complete execution path through devops-lib — every stage, every decision point, every policy check — with exact code locations | High | DevOps Platform |
| [`library-impact-analyzer`](./library-impact-analyzer/SPEC.md) | Given a devops-lib PR, identify which build_tool types, pipeline stages, and consumer service categories are affected — so reviewers know the blast radius before merging | High | DevOps Platform |
| [`build-failure-debugger`](./build-failure-debugger/SPEC.md) | Given a Jenkins job log from a failed devops-lib build, identify exactly which stage failed, trace the code path through devops-lib that produced the failure, and output a concrete fix | High | DevOps Platform |
docs/skills/build-failure-debugger/SPEC.md
+129
View File
@@ -0,0 +1,129 @@
# Skill: build-failure-debugger
**One-line description:** Given a Jenkins job log from a failed devops-lib build, identify exactly which stage failed, trace the code path through devops-lib that produced the failure, and output a concrete fix with the exact file and line driving the error.
**Owner:** DevOps Platform team
---
## Why this skill exists
Jenkins job logs are long, noisy, and mixed-language (Groovy stack traces, Maven output, Docker build output, ArgoCD sync output). When a build fails, an engineer must:
1. Scroll through 2000+ lines to find the failure point
2. Know that "Build" maps to `buildMaven.groovy`, "Deploying to ArgoCD" maps to `deployArgoCD.groovy`, etc.
3. Know which code path was taken based on `build_tool` and `cicd_environment`
4. Know which external system (GAR, SonarQube, ArgoCD, Helm repo) caused the failure vs which devops-lib logic caused it
The mapping from Jenkins stage names to devops-lib source files is non-obvious and not documented anywhere. A "SonarQube Quality Gate" failure could mean: the threshold was breached, the project doesn't exist in Sonar yet, or a whitelist entry is missing. Three different fixes, identical log output.
This skill knows the stage-to-file mapping, the code paths for each failure mode, and the set of conditions that trigger each error.
---
## Trigger
- User pastes a Jenkins job log (or the relevant failure excerpt)
- `"this Jenkins build failed, help me debug it"` with log attached
- `"sonar quality gate failing for auth-service on develop"`
- `"build stuck at ArgoCD sync for catalog-service in prd"`
- Proactively: when a user shares a build URL, fetch the log and diagnose
---
## Input
- Jenkins job log (pasted text or URL to the Jenkins job)
- Optionally: the service `config.yaml` (to know `build_tool`, `skip_sonar`, `deployArgo`, etc.)
The skill can infer build_tool and environment from the log itself if config.yaml is not provided (Jenkins prints `build_tool` and `cicd_environment` at pipeline start via `constructParam.run()`).
---
## Expected output
Given: Jenkins log showing failure in "Deploying to ArgoCD" stage for `catalog-service` on `develop`
```
Build Failure Debug — catalog-service | branch: develop | env: stg
Stage failed: Deploying to ArgoCD
devops-lib: src/com/meesho/utilities/deployArgoCD.groovy
Step that failed: update_helm_repo (step 3 of 4)
Error in log: ERROR: Helm push failed — chart version 0.1.142 already exists
Root cause: The Helm chart version was not bumped between this push and the previous
build. deployArgoCD.groovy uses the image SHA as the chart version suffix, but the
SHA collision occurred because the source didn't change (config-only build — latest
tag was reused from GAR without a new image build).
Fix: Force a source change to generate a new image SHA, OR bump the chart version
manually in devops-argo-config.
deployment_order check: 'catalog-service-stg' — verify this matches the app name
in devops-argo-config (wrong name → silent sync failure at step 4, not step 3).
Relevant code:
deployArgoCD.groovy:update_helm_repo() — pushes chart with SHA-derived version
constructParam.groovy:getConfigOnlyChange() — sets SKIP_BUILD flag when only YAMLs changed
```
---
## Stage-to-file mapping (built-in knowledge)
| Jenkins stage name | devops-lib file |
|---|---|
| `Build` | `buildMaven.groovy` / `buildGo.groovy` / `buildNode.groovy` / etc. (by `build_tool`) |
| `Docker Build & Push` | `buildMaven.groovy:dockerBuildAndPush()` / equivalent in each build stage |
| `SonarQube Analysis` | `buildMaven.groovy:sonar_scan()` / `buildGo.groovy:sonar_scan()` |
| `SonarQube Quality Gate` | `constructParam.groovy:waitForQualityGate()` |
| `CAC Validation` | `buildMaven.groovy:cac_validation()` / `buildGo.groovy:cac_validation()` |
| `Deploying to ArgoCD` | `deployArgoCD.groovy` (4-step: update_argo_repo → refresh_app_of_apps → update_helm_repo → refresh_and_sync) |
| `Notify` | `notify.groovy` / `notifySlack.groovy` |
| `AppConfig Validation` | `constructParam.groovy:validateAppConfig()` |
---
## Failure mode taxonomy
The skill classifies every failure into one of these categories before diagnosis:
| Category | Signal in log | devops-lib location |
|---|---|---|
| Build compilation | `BUILD FAILURE` / `go build failed` | build<Lang>.groovy |
| Docker push to GAR | `denied` / `UNAUTHORIZED` on push | build<Lang>.groovy:dockerBuildAndPush() |
| Sonar threshold | `Quality Gate status: FAILED` | constructParam.groovy:waitForQualityGate() |
| Sonar project missing | `Project not found` | buildGo.groovy:sonar_scan() auto-create logic |
| ArgoCD step 1 (argo_repo update) | `git push failed` in argo-config repo | deployArgoCD.groovy:update_argo_repo() |
| ArgoCD step 2 (app-of-apps refresh) | `app not found` / `no Application object` | deployArgoCD.groovy:refresh_app_of_apps() — new service, ArgoCD app not yet created |
| ArgoCD step 3 (helm push) | `chart version already exists` | deployArgoCD.groovy:update_helm_repo() |
| ArgoCD step 4 (sync) | `OutOfSync` / `Helm values error` | deployArgoCD.groovy:refresh_and_sync() |
| Wrong deployment_order | Silent sync on wrong app name | config.yaml:deployment_order vs devops-argo-config |
| Multizone gate | `must be deployed via Ringmaster` | constructParam.groovy:isMultizoneEnabled() |
---
## Dependencies
- Full read access to devops-lib source (stage-to-file mapping, failure message strings)
- Jenkins log (pasted by engineer or fetched via Jenkins API)
- Optionally: `Meesho/whitelists` (to check if skip_sonar or multizone entries explain the failure)
- Optionally: `Meesho/devops-argo-config` (to validate `deployment_order` app names for ArgoCD failures)
---
## Design notes
- The skill must handle truncated logs (Jenkins UI often shows the last N lines). It should ask for the full log if the failure point is not visible.
- For hotfix builds: sonar and quality gate failures are expected to be suppressed; if they appear, the hotfix path was not taken — the skill should check the branch name pattern.
- The skill should distinguish between a devops-lib bug (code path is wrong) vs a configuration error (wrong value in config.yaml or whitelist) vs an external system error (GAR down, Sonar unreachable).
---
## Open questions
- Should it auto-fetch the Jenkins log via the Jenkins API if given a job URL?
- For ArgoCD step 4 failures (Helm values schema errors): should it parse the exact Helm error and cross-reference with the deployment.yaml schema?
- Should it suggest a rerun command or ArgoCD force-sync as a recovery action?
docs/skills/library-impact-analyzer/SPEC.md
+73
View File
@@ -0,0 +1,73 @@
# Skill: library-impact-analyzer
**One-line description:** Given a devops-lib PR, identify which build_tool types, pipeline stages, and consumer service categories are affected — so reviewers know the blast radius before merging.
**Owner:** DevOps Platform team
---
## Why this skill exists
devops-lib is consumed via `@Library('devops-lib@main')` by every Meesho microservice. A change to a shared file like `constructParam.groovy` or `buildObjHelper.groovy` can silently affect hundreds of services across all build types and environments. There is currently no tooling to answer the basic pre-merge question: **"what does this change actually affect?"**
Common dangerous patterns caught too late:
- A change to `constructParam.groovy:run()` that's tested on maven but breaks node builds (different code path)
- A change to `buildGo.groovy` that fixes prd but changes stg behavior (env-conditional logic)
- A change to `eksCICD.groovy:allowedUsers` that accidentally narrows who can trigger builds
The review process today is manual — a senior DevOps engineer reads the diff and mentally simulates which build types it touches. This is error-prone and doesn't scale as the library grows.
---
## Trigger
- PR opened against devops-lib (automatic on any PR touching `src/`, `vars/`, or `resources/`)
- Manual: `"what does this PR affect?"` with a PR number or diff pasted
- `"impact analysis for PR #643"`
---
## Expected output
Given PR touching `src/com/meesho/utilities/constructParam.groovy` and `src/com/meesho/stages/buildGo.groovy`:
```
Impact Analysis — PR #643
Files changed: constructParam.groovy, buildGo.groovy
Affected build paths:
✦ constructParam.groovy is called by ALL build types on EVERY build
→ Changes here affect: maven, go, node-*, python-*, gradle, php, rust, docker
→ Changes here affect: ALL environments (prd, stg, int, ftr)
Changed method: skipSonarCheckForGo() — new method, additive, low risk
✦ buildGo.groovy affects: go, go-1.22, go-1.21 (any build_tool matching /^go.*/)
→ Environments: prd + stg (sonar_scan() only runs in these envs)
Changed: sonar_scan() — adds exclusion logic and auto-project creation
Risk assessment:
constructParam.groovy: LOW (new method only, no existing method modified)
buildGo.groovy: MEDIUM (modifies sonar_scan() which runs in prd)
Suggested test coverage before merge:
□ Trigger a Go service build in stg to verify sonar exclusions work
□ Trigger a Maven service build to confirm constructParam changes are neutral
□ Check sonar_scan() does not break for services without sonar-project.properties
```
---
## Dependencies
- Reads devops-lib source to build a call graph (which methods call what, which build_tool routes to which stage)
- `git diff` of the PR (from `gh pr diff <number>` or GitHub API)
- Optional: `Meesho/whitelists` to identify which consumer repos are on relevant whitelists
---
## Open questions
- Should it post the impact analysis as a PR comment automatically (requires GitHub token), or output to stdout?
- Should it attempt to enumerate actual consumer services affected (requires access to consumer repos), or stop at build_tool categories?
- Should it flag changes to `allowedUsers` lists as HIGH risk automatically (any change to who can trigger builds is sensitive)?
docs/skills/pipeline-tracer/SPEC.md
+112
View File
@@ -0,0 +1,112 @@
# Skill: pipeline-tracer
**One-line description:** Given a service's config.yaml and a branch/trigger context, trace the complete execution path through devops-lib — every stage, every decision point, every policy check — and output a human-readable flow with the exact code locations driving each step.
**Owner:** DevOps Platform team
---
## Why this skill exists
devops-lib's pipeline is a routing tree, not a linear script. A single `eksCICD` call dispatches to different stages based on `build_tool`, takes different paths based on `env.BRANCH_NAME` and PR target, checks multiple whitelists, conditionally runs sonar, CAC validation, ArgoCD sync, and sends different notifications depending on the environment. The full execution path for a given service in a given context spans 15+ files.
No one has a complete mental model of this tree for every service type. Consequences:
- Engineers add a whitelist exception but don't know which of the 3 sonar-skip checks it actually bypasses
- Reviewers approve a stage change without knowing it only runs in `prd` (not `stg`)
- New team members spend days understanding why their build skips certain stages
- Debugging requires mentally simulating the entire dispatch chain from `eksCICD.groovy` down
This skill is the complement to `library-impact-analyzer`: impact-analyzer answers "what does a code change affect?" — pipeline-tracer answers "for this specific service in this specific context, what exact path does the code take?"
---
## Trigger
- `"trace pipeline for payment-service on develop branch"`
- `"what stages run for a hotfix build of catalog-service?"`
- `"why is sonar being skipped for auth-service?"`
- `"show me the full pipeline path for a PR from feature/x to main in supply-chain-service"`
- Proactively: attached to `service-onboarder` output — show the new service's expected pipeline before its first build
---
## Input
- A service `config.yaml` (file path or pasted content) — provides `build_tool`, `team`, `bu`, `skip_sonar`, `deployArgo`, `deployment_order`, etc.
- A trigger context: branch name (`develop`, `main`, `hotfix/x`, `feature/y`) and optionally a PR target (`main` or `develop`)
---
## Expected output
Given: `config.yaml` for `payment-service` (build_tool: maven, bu: supply), branch: `develop`
```
Pipeline Trace — payment-service | branch: develop | env: stg
Entry point: vars/eksCICD.groovy
Trigger check: PASS — develop branch, no PR target → env = stg
Pod selection: resources/org/meesho/stg-pod.yaml
image: build-tools:lunar-v2.0.21
node pool: supply-shared (BU-scoped stg pool)
Build stage: src/com/meesho/stages/buildMaven.groovy
build_tool 'maven' → buildObjHelper → buildMaven
Config-only change check: RUNS (skips build if only *.yaml changed)
Docker image: stg/payments/payment-service:<sha>
Policy checks:
skip_sonar: false → sonar WILL run
skip-sonar-whitelist: payment-service NOT on list → sonar runs
CAC validation: payment-service on ValidateCacConfig whitelist → RUNS
appConfigEnabled: true → AppConfig validation RUNS
multizone: payment-service NOT on multizone list → deploy proceeds normally
ArgoCD deploy:
deployArgo: true → WILL deploy
deployment_order: [payment-service]
4-step sequence: update_argo_repo → refresh_app_of_apps → update_helm_repo → refresh_and_sync
ArgoCD app: payment-service-stg
Notification:
notify_channel: #payments-alerts
Ringmaster callback: NO (stg build, not prd)
Turbo-Turtle callback: YES (stg deploy confirmation)
Total stages: 7 | Estimated duration: 12–18 min
```
---
## Dependencies
- Full read access to devops-lib source (the skill builds a live call graph from the source)
- `Meesho/whitelists` read access (to check live whitelist membership for the specific service)
- `src/com/meesho/utilities/buTeamMapping.groovy` (for node pool selection)
- `resources/org/meesho/*.yaml` (for pod spec and image resolution)
---
## Design notes
The skill must understand the devops-lib environment mapping table precisely:
| Branch | PR target | `cicd_environment` |
|---|---|---|
| `main`/`master`/`gcp-main` | — | `prd` |
| `develop` | — | `stg` |
| any | `main` | `int` |
| any | `develop` | `ftr` |
| `hotfix/*` | — | `prd` (sonar + tests skipped) |
And must correctly simulate the hotfix path (sonar skipped, quality gate skipped, no CAC validation) vs the standard path.
---
## Open questions
- Should the trace show actual code line numbers for each decision, or just method names?
- For `int` and `ftr` environments where ArgoCD deploy is often skipped: should it explain why?
- Should it compare two contexts side-by-side (e.g., "what's different between develop and hotfix builds for this service")?
- Could this skill power an interactive pipeline visualiser (Mermaid diagram output)?