Turn passing Buildkite deploys into customer-ready release notes

Poll Buildkite for finished builds, and whenever a build finishes on my production deploy pipeline, turn that release into customer readable release notes. Only continue when the build's state is passed and the build belongs to my production deploy pipeline. Ignore failed and canceled builds, and ignore builds on every other pipeline.

Start by using Buildkite's Get a Build operation to pull the full record for the build that just finished, so you know exactly what shipped: the commit SHA, the branch, the pipeline, and the time the build finished. Buildkite addresses builds by their per pipeline sequential number, not by the UUID id, and most Buildkite paths are scoped by organization slug, so look up the organization slug first if you need it.

Next, establish the start of the release window. Use Buildkite's List Builds for a Pipeline operation against the same production deploy pipeline, filtered to passed builds, to find the previous successful deploy before this one. Take the time that build finished as the lower bound of the range. If there is no previous successful deploy, fall back to the last 7 days so the first run still produces something sensible.

Now gather what actually shipped. Use GitHub's List Pull Requests operation on the repository, filtered to closed pull requests with the main branch as the base and sorted by most recently updated. Keep only pull requests that were genuinely merged, and only those merged between the previous successful deploy and this build. Do not attempt a commit range comparison, since a compare commits operation is not available here. The merged pull request list bounded by those two deploy timestamps is the definition of this release.

Then do the editorial work. Group the changes into three sections: New, Improved and Fixed. Rewrite every item in plain language aimed at a non engineering reader, describing the benefit or the behavior change rather than the implementation. Turn a title like refactor session token refresh path into something a customer would understand, such as fixed an issue where you could be signed out unexpectedly. Drop internal only work entirely, including dependency bumps, CI and build configuration changes, test only changes, and pure refactors with no user visible effect. Where a pull request title is too cryptic to interpret confidently, use its description for context, and leave it out rather than guessing.

If every merged pull request in the range turns out to be internal only, skip the run entirely. Do not append anything to Notion and do not post to Slack, so we never publish an empty release note.

When there is at least one customer facing change, append the finished notes to our Notion changelog page using the Append Block Children operation. Add it as a new dated entry on the existing page rather than creating a new page: a heading with the release date, then only the sections that have content, each with its items as bullets. Keep the existing entries untouched so the page reads as a running changelog with the newest release at the end.

Finally, post a short summary into Slack using the Slack Bot Send a Message operation, so support and customer success know what changed before customers start asking. Keep it to a few lines: the release date, a one sentence sense of the headline changes, the counts per section, and a link to the Notion changelog page for the full detail. Do not paste the entire release notes into the channel.