# 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)?