Notifications

notify.groovy runs in the pipeline's finally block — it always executes regardless of build outcome. It routes to different backends based on who triggered the build and what environment the build ran in.

TL;DR

ringmaster-bot or turbo-turtle triggered → calls deployRingmaster.run() + Slack on prd.
All other users → direct Slack slackSend only.
Toolchain env → HTTP callback to 172.23.72.116:5002/api/v1/deploy/build-callback (skip Slack/Ringmaster).
On prd push builds, also posts to deployment-tracker API and Ringmaster deployment history.
notify_channel comes from config.yaml; defaults to ci-cd-status if empty.

Mental model

notify.run() is the final stage in commonCICDFlow. Since it's in a finally block, env.msg carries the final build status message (set by each catch block in commonCICDFlow). The notification backend selection depends on the triggering user, not on the environment:

ringmaster-bot → Ringmaster API (/api/v1/key/cicd/cd/update) with a token-authenticated payload.
Turbo-Turtle or other allowed users → Turbo-Turtle callback (/api/v1/ci/jenkins/callback) via a temporary JSON file to avoid shell quoting issues.

Structure / data flow

notify.run(config):
  ├─ [toolchain] if env.INFRA_ENV == 'toolchain':
  │    POST http://172.23.72.116:5002/api/v1/deploy/build-callback
  │    return  (skip everything below)
  │
  ├─ build_user = getCause(UserIdCause).getUserId()
  │
  ├─ if build_user in [ringmaster-bot, turbo-turtle]:
  │    deployRingmaster.run(...) → POST to Ringmaster or Turbo-Turtle
  │    if prd: slackSend(notify_channel, deploy URL)
  │    skip_notify = true
  │
  ├─ if !skip_notify:
  │    slackSend(notify_channel, job name + build number + tag + msg)
  │
  └─ if main/master branch:
       postTrackingApi(config)      ← deployment-tracker API
       postTrackingRingmasterApi(config)  ← Ringmaster deployment history

deployRingmaster.run(repo_name, deployment_order, tag, ...):
  if build_user == "ringmaster-bot":
    POST https://ringmaster-api.meeshogcp.in/api/v1/key/cicd/cd/update
  else:
    POST http://turbo-turtle.meeshogcp.in/api/v1/ci/jenkins/callback

Key code locations

Symbol	File	What it does
`run`	`src/com/meesho/stages/notify.groovy:run`	Main notify dispatcher
`postTrackingApi`	`src/com/meesho/stages/notify.groovy:postTrackingApi`	Posts to deployment-tracker API
`postTrackingRingmasterApi`	`src/com/meesho/stages/notify.groovy:postTrackingRingmasterApi`	Posts to Ringmaster deployment history
`run`	`src/com/meesho/stages/deployRingmaster.groovy:run`	Routes to Ringmaster or Turbo-Turtle callback
`callApi`	`src/com/meesho/stages/deployRingmaster.groovy:callApi`	Ringmaster API call with `ringmaster-token` credential

Sharp edges

JSON payload via temp file (Turbo-Turtle path): the Turbo-Turtle curl call writes the payload to a temp file (cicd_payload_${BUILD_NUMBER}_${ts}.json) to avoid shell quoting issues with JSON special characters. The file is always deleted in a finally block.
prd vs int API endpoints: for both Ringmaster and deployment-tracker, prd and int share the ringmaster-api.meeshogcp.in endpoint while stg/ftr use ringmaster-api.admin.meeshogcp.in.
skip_notify is env.* not config.*: it's set by constructParam.run() (always true for GCP) and can also be set by the consumer config.yaml. Both must be false for Slack to fire.
env.msg is the error channel: each catch block in commonCICDFlow sets env.msg before the finally block calls notify. If nothing failed, env.msg stays 'Job Passed'.

Ringmaster integration — detailed routing logic
Architecture — where notify fits in commonCICDFlow
Environment mapping — cicd_environment determines API base URL

Notes

← Previous · Index · Next →

4.4 KiB Raw Blame History