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

3.3 KiB Raw Blame History