added files
This commit is contained in:
Your Name
@@ -0,0 +1,112 @@
|
||||
# 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)?
|
||||
Reference in New Issue
Block a user