How to Announce a GitHub Release on Social Media Automatically (and Where a Workflow Stops)

TL;DR: To announce a GitHub release on social media automatically, trigger a workflow on the release: published event, turn the release notes into a short post, and send it to each network. That works well for one text-and-link post on X or Bluesky. It breaks down when each platform needs different copy, or when the networks you care about have no free write API.

You tag v2.4.0, write the release notes, hit publish, and then spend twenty minutes shortening the changelog for X, rewriting it for LinkedIn, and pasting a link into Mastodon. Two releases later you forget one of the three. Release announcements are the most repeatable posting job a maintainer has, which makes them a good first thing to automate, and a good test of where automation stops being cheap.

The trigger: release: published, and two traps

GitHub Actions fires on release activity with these types: published, unpublished, created, edited, deleted, prereleased, released. The docs add two notes that decide which one you want:

• Workflows are not triggered for created, edited or deleted on draft releases. If you create releases through the GitHub UI, they may be saved as drafts first.
• prereleased does not fire for pre-releases published from a draft, but published does. GitHub’s own advice: subscribe to published instead of released plus prereleased.

So the safe trigger is:

on:
  release:
    types: [published]

Subscribing to created or edited is how people end up posting the same release three times, once when it is created, again when someone fixes a typo in the notes. Keep edited out unless you deliberately want re-announcements.

Three ways to wire it up

The hub route is worth a look if you maintain several projects. git-tweet’s own README describes the flow as GitHub Release, signed webhook or scheduled poll, policy and dedup, X and Bluesky, then a delivery log, with release-first rules so a release and its tag do not both post. That dedup problem is the real one, and a per-repo workflow has to solve it yourself.

What a workflow step can and can’t reach

A release announcement is a short post: version, one line about what changed, a link. For that, the cheap options are real:

• Bluesky talks open AT Protocol endpoints, so a script with an app password is enough. We cover it in auto-posting to Bluesky.
• Mastodon takes a plain access token against your instance (Mastodon guide).
• X works, but writing costs money on the current API, which we go through in scheduling posts to X.

Then the walls show up. LinkedIn’s write access sits behind developer review, Reddit closed self-service API access and asks for manual approval, and Medium’s API is closed to new integrations. A fixed workflow can only post where you hold a credential, so the platforms where devs actually read release news are often the ones you cannot reach. Several of those gates are covered in the posts on LinkedIn and Reddit.

The second limit is copy. One template sent everywhere reads as a bot. A tweet-length “v2.4.0 is out” is fine on X. A LinkedIn post wants the why, and a Reddit post in a project subreddit wants context and no bare link. Our post on what has to change before you post one draft to six platforms has the per-platform rules.

Using an AI agent instead of a template

The agent route swaps the template for a step that reads the release body, decides which networks are worth posting to for this release (a patch fix probably is not), and writes copy per platform. Where PublishPort fits: it gives that agent two tools, list_capabilities and local_bash, and the agent reads each command’s --help to learn how to post. Publishing happens through your own logged-in browser, so there is no per-network developer app to register. The wiring is in running opencli from a remote AI agent, and plans are on the pricing page.

The honest caveat: it needs the desktop client running and logged in on your machine, so it is not something a GitHub-hosted runner does by itself. A practical split is to let the workflow do the trigger and the notification, and let the agent session on your machine do the posting. It also decides per post, so it can misjudge. Do not let it publish unattended on day one.

A setup that works for a solo maintainer

1. Trigger on published only. Skip drafts and edits.
2. Post the plain text-and-link version to Bluesky or Mastodon straight from the workflow. Cheap, and it fails loudly.
3. Hand the release body to an agent for the networks that need real copy (LinkedIn, Reddit, a Dev.to write-up).
4. Dry-run first. Have the agent print each post without sending. Testing an agent before it posts walks through how.
5. Keep one approval step until you have watched a dozen releases go out clean.
6. Store the post URL in a file or the release notes so a re-run does not post twice.

Also mind human pace and platform rules. Announcing your own release once is normal. Reposting the same link across many subreddits is what gets removed.

FAQ

Can GitHub Actions post to social media when I publish a release?

Yes. Use the release event with the published type, then call a posting action or script. You need a credential for every network you post to, and some networks make that hard to get.

Which release event should I use to avoid duplicate posts?

published. GitHub’s docs say it also fires for pre-releases published from a draft, whereas prereleased does not. Avoid created and edited, which fire on changes and typo fixes.

Should the announcement use the full changelog?

No. A post is version, one line of what matters, and a link to the notes. Pull one or two headline items rather than the whole list.

Can an AI write the release announcement for me?

It can draft one per platform from the release body. Review the first several by hand, since it can overstate or misstate a change.

How do I stop an announcement from posting twice?

Trigger on published only, keep a record of what was posted per tag, and pick a tool with deduplication if you run many repos.