[gorandodig]

Each release now posts one Slack message. The result notices reply in its thread, using the ts output of the start post.

• Failure notices are also broadcast to the channel (reply_broadcast). Success stays in the thread and adds a ✅ reaction to the start notice. This needs the reactions:write scope on the Slack app; the step is non-fatal until it is granted.
• If the start notice never posted, thread_ts renders as YAML null. The Slack client drops null fields, so notices post to the channel as before. An empty string would be sent as-is, which is why null is used.
• thread_ts is quoted so YAML keeps the timestamp a string rather than a float.
• Notices that can only fire before the start notice exists (failed checks or tests, and one-message paths) are unchanged.

Summary by CodeRabbit

• Chores
  • Release status notifications are grouped into Slack threads when a start notification is available. Failure updates are broadcast in the thread, while successful pre-release and release updates remain threaded without broadcasting. If no start notification timestamp is available, updates are sent without a thread.
  • After a successful PyPI publish, the workflow attempts to react to the start notification with a ✅. A reaction failure does not interrupt the workflow.

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: Unavailable
• Branch: Unavailable
• File: No configuration file from this repository applied
• Commit: Unavailable
• Layers: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: 65793d61-6b7a-4b7e-a1d3-95718fddaf96

Commits

Reviewing files that changed from the base of the PR and between 7db543e and f53af02.

Files selected for processing: 1

• .github/workflows/publish-to-pypi.yml

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 6 remain after this review.

Walkthrough

The PyPI publishing workflow captures the timestamp of its start Slack message and passes it to the notification job. Result notices reply in that thread when the timestamp is available. Failure replies are broadcast. After a successful PyPI publish, the workflow attempts to add a ✅ reaction to the start message.

Changes: Release notifications

Layer / File(s)	Summary
Capture and pass the Slack timestamp .github/workflows/publish-to-pypi.yml	The build job exports the start message timestamp. The notification job uses it when available and sets THREAD_TS to null when it is absent.
Thread result notices and react after publish .github/workflows/publish-to-pypi.yml	Failure and success notices reply in the start message thread when its timestamp is available. Failure replies are broadcast. After a successful PyPI publish, the workflow attempts to add a ✅ reaction to the start message and continues if the reaction fails.

Priority: Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Feature

Sequence Diagram(s)

sequenceDiagram
  participant BuildJob
  participant Slack
  participant NotifyJob
  BuildJob->>Slack: Post start notice
  Slack-->>BuildJob: Return message timestamp
  BuildJob->>NotifyJob: Pass slack-ts
  NotifyJob->>Slack: Post result notice in thread when timestamp exists
  NotifyJob->>Slack: Add reaction after successful PyPI publish when timestamp exists

Loading

Possibly related PRs

• plainlang/plain-parser#16: Creates the workflow notification jobs and the start Slack notice that this change uses for threaded result notices.

Merge Risk: Minimal · up to f53af

The release notification changes are mergeable with no established functional or operational risk.

Architecture risk: Low · up to f53af

The changed surface does not map to a changed system, dependency edge, entrypoint, or external dependency.

Changed systems: None identified.

Architecture concerns
No architecture-level concerns identified.

Review details

Before / after behavior

• observed — Modified behavior in .github/workflows/publish-to-pypi.yml: The build job now exposes the start Slack notice timestamp through the slack-ts job output, sourced from the slack-start step.
• observed — Modified behavior in .github/workflows/publish-to-pypi.yml: The start Slack notification step now has the slack-start ID, allowing its timestamp to be referenced by the build job output.
• observed — Modified behavior in .github/workflows/publish-to-pypi.yml: The notify job now sets THREAD_TS from the build output, quoting a present timestamp and using null when it is absent. The added comments specify that notices use the thread when available and fall back to channel posts when it is not.
• observed — Modified behavior in .github/workflows/publish-to-pypi.yml: The build-failure Slack notice now includes the thread timestamp and broadcasts the reply when a thread timestamp exists.

Pre-merge checks: 4

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title names the main change: Slack release notices now reply in the thread of the start notice. The raw summary confirms the build job exposes the start-notice slack-ts, and build, upload, PyPI …
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Title check

Explanation

The title names the main change: Slack release notices now reply in the thread of the start notice. The raw summary confirms the build job exposes the start-notice slack-ts, and build, upload, PyPI failure, pre-release, and release success notices reply in that thread. The title's scope prefix ci(release) matches the edited publish workflow. The title is concise, specific, and does not describe unrelated work. The title does not mention the ✅ reaction, but that is a secondary detail.

Finishing Touches

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[bananaplain]

@gorandodig @coderabbitai This buries the "success" message inside a thread. Is there a solution that would make the "end result" visible on top-level?

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
ast-grep outline .github/workflows/publish-to-pypi.yml
rg -n -C 8 'reply_broadcast|thread_ts|THREAD_TS|slackapi|slack-start|chat.postMessage' .github/workflows/publish-to-pypi.yml

Length of output: 7407

---

🤖 web_search executed:

Slack chat.postMessage official documentation reply_broadcast true thread_ts reply visible channel thread broadcast

Length of output: 5276

---

@bananaplain Yes. Broadcast the success reply to the channel, as this PR already does for failure replies.

In .github/workflows/publish-to-pypi.yml, add this field to both success payloads: Notify Slack (pre-release published) and Notify Slack (release published).

thread_ts: ${{ env.THREAD_TS }}
reply_broadcast: ${{ env.THREAD_TS != 'null' }}

This keeps the result in the thread and also shows a reference to the reply in the channel timeline. Slack supports this through reply_broadcast. If no start timestamp exists, the existing fallback still posts the result directly to the channel.

This is the smallest change that makes the final result visible at the top level without losing the thread.

_{You are interacting with an AI system.}

[bananaplain]

Yes. Broadcast the success reply to the channel, as this PR already does for failure replies.

Or we could do a ✅ react on the top-level post instead @coderabbitai

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@bananaplain Yes. A ✅ reaction on the top-level start message would show success without adding another channel message.

Use Slack’s reactions.add with name: white_check_mark, the start message’s channel, and its ts. The bot needs the reactions:write scope.

Keep the success details in the thread and keep failure replies broadcast. If no start message exists, keep the current channel-post fallback.

One trade-off: the reaction marks the original message, but does not move it to the latest position in the channel.

_{You are interacting with an AI system.}

[bananaplain]

@coderabbitai i think the current branch state is now cute 👍 will approve

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@bananaplain Glad you’re happy with the result! 👍

_{You are interacting with an AI system.}