added files

2026-08-26 02:02:24 +05:30
parent 58ee8a276a
commit 3419cfba0c
200 changed files with 22132 additions and 0 deletions
@@ -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)?