DEVEX-1654: parse rt tag format in deploy notifications (Slack + Jellyfish)#136
DEVEX-1654: parse rt tag format in deploy notifications (Slack + Jellyfish)#136pdodgen-revparts wants to merge 1 commit into
Conversation
Phase 4 of Release Train v2 (DEVEX-1654). Adds a parse step to both slack-deploy-notification.yaml and jellyfish-deploy-notification.yaml that classifies the image_tag input into one of: * v2 (RT v2): vX.Y.Z-rc.<YYYY-MM-DD>.<iter> → captures train_date + iter * v1 (legacy): vX.Y.Z-rc.<iter> → captures iter * plain: vX.Y.Z → 'clean release' * unknown: anything else → passthrough Slack message now reads, e.g., 'listings-url-service deployed — train 2026-06-18 · rc.3' instead of just the bare tag string. Captains can read the train and rc iter at a glance from #releases. Jellyfish event 'name' field gets a parenthetical suffix containing train + iter. Useful for the Phase 6 captain-handbook dashboard plotting iter@promotion per train per app over time. The reference_id is unchanged so existing dashboards don't break. Dual-format support is the migration-window concern from DEVEX-1654: during Phase 3 rollout, both v1 and v2 tags coexist; parsers handle both without an if/else at the caller layer. Verified the regex against likely tag formats: v4.7.0-rc.2026-06-18.3 → v2, train=2026-06-18, iter=3 v4.7.0-rc.7 → v1, iter=7 v4.7.0 → plain v4.7.0-rt.147.rc.3 → unknown (the abandoned spec format)
PR SummaryLow Risk Overview Slack notifications now include a short summary (e.g. train 2026-06-18 · rc.3) in the message text and block body instead of only the raw tag. Jellyfish deployment event Non-matching tags still notify: Slack falls back to the raw tag or “clean release”; Jellyfish leaves the name suffix empty. Reviewed by Cursor Bugbot for commit e8c11c2. Bugbot is set up for automated code reviews on this repo. Configure here. |
1 participant
Phase 4 of Release Train v2 (DEVEX-1579 / DEVEX-1654). Self-contained.
What changes
Both
slack-deploy-notification.yamlandjellyfish-deploy-notification.yamlgain a parse step that classifiesimage_taginto v2 / v1 / plain / unknown:v4.7.0-rc.2026-06-18.3v4.7.0-rc.7v4.7.0Slack message now reads
listings-url-service deployed — train 2026-06-18 · rc.3instead of just the bare tag. Captains see the train + iter at a glance in #releases.Jellyfish event
namefield gets the same parenthetical suffix;reference_idis unchanged so existing dashboards don't break.Why now
Dual-format parsing is a stated DEVEX-1654 deliverable. Landing it before any v2 train cuts means the first real RT v2 promote will already surface 'rc.X of train YYYY-MM-DD' in #releases. Without this PR the Slack notification would just show the bare
v4.7.0-rc.2026-06-18.3string, which is functional but not glanceable.Risk
Low. Both workflows are reusable (
workflow_call). Existing callers don't change shape. If the parse step's regex misses an edge case, it falls into theunknownbranch and the notification still fires with the raw tag — no regression vs. today.Not in this PR