| ci: automate Slack deploy notifications to #deploys (#6316) ## Problem Deploys are announced manually in the engineering channel, which is easy to forget and clutters the wrong channel. There's no passive, reliable awareness of who is deploying what, where. ## Solution Notify [#deploys](https://nangohq.slack.com/archives/C0B7KSD33QE) automatically on every `workflow_dispatch` deploy, via a reusable composite action at `.github/actions/slack-deploy-notification`: - `notify_start` posts a status message with a colored bar (blue) showing the service, stage, ref, who triggered it, and a link to the run. It runs independently of the deploy jobs, so Slack never delays or blocks a deploy. - `notify_result` updates that same message in place once the deploy finishes: - ✅ green — `Deploy succeeded in 2m 37s` - ❌ red — `Deploy failed after 2m 37s` - ⚠️ yellow — `No deploy ran` when no job matched the service/stage (e.g. `runner`/`lambda` on `replit`), so a no-op never reports success. Covers all services (`server`, `jobs`, `runner`, `persist`, `orchestrator`, `metering`, `connect_ui`, `app_ui`, `lambda`) and all stages (dev / staging / prod / replit). The workflow also gains a least-privilege `permissions: {}` block, granting `contents: read` only to the jobs that check out the repo. ### Slack setup (done) The **Nango CI** Slack app (scope `chat:write`) is installed and invited to `#deploys`, and its bot token is stored as the `SLACK_BOT_TOKEN` repository secret. A bot token is required because incoming webhooks can't do `chat.update`. Fixes [NAN-5643](https://linear.app/nango/issue/NAN-5643) ## Testing - Triggered `app_ui` and `connect_ui` deploys to `development` from this branch and confirmed the `#deploys` message transitions in place from blue "Deploy started" to green "Deploy succeeded in Xm Ys". - Verified the composite action resolves in both notify jobs and that the `permissions: {}` block doesn't break checkout. | 3 个月前 |