Release announcements
Ship a release, and ReachPill turns the release notes into on-brand posts across your channels — and, optionally, a blog article — with zero extra steps. No codebase access required.
Announce releases from a repo
Add the repo
In
Settings → Connections, find the GitHub section and its Release announcements row. Hit Add a repo and enter the repository asowner/repo.Pick how ReachPill hears about releases
Three ways, none of which hand over your code — see the access options below.
Choose where it posts
Pick the social channels each release should post to, and whether to also draft a blog article. At least one channel (or the blog) is required — otherwise there's nothing to generate.
Choose the review style
Review each release, auto-approve after a wait, or publish automatically. Whatever you pick, the first release always waits for your review, so you see a real post before anything goes hands-off.
Three ways to connect — no code grant
- Public repo— ReachPill watches the repo's public releases feed. Nothing to install, nothing to grant.
- GitHub App — install the read-only reachpill-releases app on exactly the repositories you choose. Release events arrive instantly; works for private repos. Honest limit: GitHub has no releases-only permission, so the app holds read-only Contents access — it subscribes to release events only, and you can revoke it at any time.
- From your CI — a short GitHub Action in the repo posts each release to ReachPill with your API key. ReachPill holds no GitHub access at all.
The CI option
For the push-based route, save this as .github/workflows/reachpill-release.ymlwith a ReachPill API key in the repo's REACHPILL_API_KEY secret (the add-repo dialog generates it pre-filled for your repo):
name: Announce release
on:
release:
types: [published]
jobs:
announce:
runs-on: ubuntu-latest
steps:
- run: |
curl -fsS -X POST https://app.reachpill.com/v1/release-events \
-H "Authorization: Bearer ${{ secrets.REACHPILL_API_KEY }}" \
-H "Content-Type: application/json" \
-d "$(jq -n \
--arg repo "${{ github.repository }}" \
--arg tag "${{ github.event.release.tag_name }}" \
--arg title "${{ github.event.release.name }}" \
--arg url "${{ github.event.release.html_url }}" \
--arg body "${{ github.event.release.body }}" \
'{repo_full_name: $repo, tag: $tag, title: $title, html_url: $url, body_markdown: $body}')"What gets announced
- Stable, published releases only — drafts and pre-releases are ignored.
- One announcement per release, deduplicated: a redelivered event never posts twice.
- Posts lead with what actually improved, grounded in your release notes and Brand DNA — never a raw changelog dump.
- Everything rides your normal review queue, campaign reporting included.
create_release_source to configure a repo and announce_release to push a release by hand. See Build with agents.