ci(frontend-deploy): report every deploy outcome in one Slack message - #8371
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 3 Skipped Deployments
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 8 included reviews per hour; 5 remain after this review. 📝 WalkthroughWalkthroughThe deploy Slack action now accepts deployment outcome and run metadata. It calculates optional start and duration fields, then renders an external Estimated code review effort: 3 (Moderate) | ~25 minutes Merge Risk: 🔵 Low · up to The workflow now reports deployed, failed, and stopped outcomes in a single Slack notification. A stopped notification may still communicate an incorrect production state if cancellation occurs after deployment begins, so merge is appropriate with explicit owner awareness or follow-up to make that wording fully state-agnostic. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #8371 +/- ##
==========================================
+ Coverage 98.79% 98.81% +0.01%
==========================================
Files 1616 1620 +4
Lines 65283 65908 +625
==========================================
+ Hits 64499 65124 +625
Misses 784 784 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
ccd5061 to
30cb8f9
Compare
30cb8f9 to
e3ac0f0
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: d8a98cd8-4121-420e-8cf2-be16a4beaa65
📒 Files selected for processing (4)
.github/actions/notify-slack-deploy/action.yml.github/actions/notify-slack-deploy/payload.jq.github/workflows/frontend-deploy-notify.yml.github/workflows/frontend-deploy-production.yml
💤 Files with no reviewable changes (1)
- .github/workflows/frontend-deploy-production.yml
Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review.
e3ac0f0 to
ac4de12
Compare
Docker builds report
|
There was a problem hiding this comment.
Actionable comments posted: 1
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: b8e569de-107b-4b51-a907-48a31de08e8c
📒 Files selected for processing (1)
.github/actions/notify-slack-deploy/payload.jq
Included review availability: Your plan provides up to 8 included reviews per hour; 6 remain after this review.
✅ private-cloud · depot-ubuntu-latest-16 — run #19883 (attempt 2)Playwright Test Results (private-cloud - depot-ubuntu-latest-16)Details
🗂️ Previous results❌ private-cloud · depot-ubuntu-latest-16 — run #19883 (attempt 1)Playwright Test Results (private-cloud - depot-ubuntu-latest-16)Details
Failed testsfirefox › tests/environment-permission-test.pw.ts › Environment Permission Tests › Environment-level permissions control access to features, identities, and segments @enterprise ✅ private-cloud · depot-ubuntu-latest-arm-16 — run #19883 (attempt 1)Playwright Test Results (private-cloud - depot-ubuntu-latest-arm-16)Details
✅ oss · depot-ubuntu-latest-arm-16 — run #19883 (attempt 1)Playwright Test Results (oss - depot-ubuntu-latest-arm-16)Details
✅ oss · depot-ubuntu-latest-16 — run #19883 (attempt 1)Playwright Test Results (oss - depot-ubuntu-latest-16)Details
✅ private-cloud · depot-ubuntu-latest-16 — run #19882 (attempt 1)Playwright Test Results (private-cloud - depot-ubuntu-latest-16)Details
✅ private-cloud · depot-ubuntu-latest-arm-16 — run #19882 (attempt 1)Playwright Test Results (private-cloud - depot-ubuntu-latest-arm-16)Details
Skipped testsfirefox › tests/onboarding-tests.pw.ts › Onboarding › New user connects via the single-page onboarding flow @oss ❌ oss · depot-ubuntu-latest-16 — run #19882 (attempt 1)Playwright Test Results (oss - depot-ubuntu-latest-16)Details
Failed testsfirefox › tests/segment-test.pw.ts › Segment test 4 - Create ANY rule type segment and verify match changes when rule is updated @oss |
The deploy channel carried three messages per deploy: a run started card and a succeeded card from the GitHub Slack app, plus our own notification. The succeeded card said nothing ours did not already say, with less detail. On 25 August that was roughly 18 messages for 6 runs. Unsubscribing the app would have lost the two states our notification never covered, so cover them here. The job now runs on always() and reports deployed, failed or stopped, and carries the run start time and duration so a separate start notification is not needed either. The outcome comes from needs.deploy-production.result rather than the run's own conclusion. deploy-demo and deploy-demo2 run alongside production, so one failed demo would otherwise report production as failed while it was serving the new release. Cancellation gets its own wording rather than the red cross the app used for it. Job level concurrency stops a run in progress whenever the next commit lands on main, so most cancellations are a supersede. It does not assert what the environment is serving, since a hand cancellation can land mid-deploy. The Block Kit payload moves to payload.jq. Inline in the action it could not contain an apostrophe, since the whole program sat inside bash single quotes, and nothing could run it directly to see what it rendered. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ac4de12 to
769f96c
Compare
Visual Regression19 screenshots compared. See report for details. |
Thanks for submitting a PR! Please check the boxes below:
docs/if required so people know about the feature.Changes
#frontend-deploygets three messages per deploy: a start card and a terminal card from the GitHub Slack app, plus our own notification. The app's✅ succeededcard duplicates ours with less detail, no commit, no actor, no link to production. On 25 Aug that was ~18 messages for 6 runs.Our notification only fired on success, so unsubscribing the app would have lost the failed and cancelled cases. This moves them here.
always()and takes its outcome fromneeds.deploy-production.result, not the run's own conclusion.deploy-demoanddeploy-demo2run alongside production, so one failed demo would otherwise report production as failed while it was serving the new release.run-testsstops a run whenever the next commit lands on main, so most cancellations mean superseded, and the app rendered those with a red cross. The copy does not assert what production is serving, since a hand cancellation can land mid-deploy.payload.jq, so it can be read and run on its own.18 messages down to 6, one per run.
Deployed
Failed
Stopped (superseded)
Follow-up, not in this PR
Once a superseded run has been reported by the new card, the app subscription needs removing from the channel by hand, otherwise the duplicates continue. Waiting for that specific case is deliberate: it is the one path that depends on
always()scheduling a job after a cancellation, which cannot be verified before merge.How did you test this code?
Rendered all three cards through Slack's Block Kit Builder using the action's real
payload.jq(screenshots above). Ranpayload.jqdirectly for every conclusion:successandcancelledget their own copy,failure,timed_outandskippedall read as failed, and with no timings supplied the Started and Duration fields drop out. Checked the timing logic in anubuntu:24.04container since it needs GNUdate -d, covering both timestamps, start only, neither, end before start, and unparseable input.Checked the outcome mapping across the seven
needs.*.resultcombinations that can occur, including production succeeding while a demo fails, which reportssuccess.Not exercised end to end, and it cannot be: this workflow only runs on push to
main. The Slack step iscontinue-on-error: trueand the job is downstream of the deploy, so nothing here can affect a deploy. The one behaviour that needs a live run is whetheralways()schedules the job after a concurrency cancellation, which is why the unsubscribe waits on seeing a supersede reported.