74 lines
3.3 KiB
Markdown
74 lines
3.3 KiB
Markdown
# 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)?
|