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

4.8 KiB Raw Blame History Unescape Escape