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