113 lines
4.8 KiB
Markdown
113 lines
4.8 KiB
Markdown
# 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)?
|