feat: add Releases collection with GitHub sync

[ncaming]

Problem

Payload's GitHub releases (payloadcms/payload) are only viewable on GitHub. There's no way for site visitors to browse release notes directly on payloadcms.com alongside blog posts and docs.

Solution

Adds a dedicated Releases collection that automatically imports GitHub releases and serves them as public pages on the website.

Key details

Releases Payload collection with GitHub metadata fields (githubReleaseId, githubTag, githubUrl, importedFromGitHub)
Public routes at /posts/releases (index) and /posts/releases/[slug] (detail)
Slug derived from GitHub tag (preserves v prefix and dots, e.g. v3.82.1)
Idempotent upsert by githubReleaseId with githubTag fallback — safe to re-run
Author resolved to "Payload Team" user; fails clearly if not found
Content stored in blogMarkdown blocks, rendered with rehype-raw for GitHub HTML
One-time seed script: pnpm payload run src/scripts/seedReleases.ts
Recurring sync via GET /api/sync-releases + Vercel cron every 4 hours
OG image route extended with releases type label
Registered with seoPlugin and redirectsPlugin
Minimal changes to existing site code

Pre-deploy checklist

- GITHUB_ACCESS_TOKEN set in Vercel env vars
- "Payload Team" user exists in production DB
- Run seed script once after first deploy

[jacobsfletch]

Initial thoughts here are that the release notes should not be saved to the db, e.g. what if they're edited on gh? Instead, we should serve the releases dynamically using gh APIs, and remove the releases collection entirely.

[ncaming]

Initial thoughts here are that the release notes should not be saved to the db, e.g. what if they're edited on gh? Instead, we should serve the releases dynamically using gh APIs, and remove the releases collection entirely.

This was intentional, as we plan to augment release notes — in some (not all) instances — when it warrants, such as community call/campaign/video or any additional narrative work that needs to join it. We will also be able to append relevant docs to major release notes.

[jacobsfletch]

In that case I still think a hybrid approach might be better, although I don't have strong feelings here. Mostly trying to avoid multiple sources of truth and the unnecessary sync.

For example, the release pages themselves could remain dynamic, e.g. pull data directly from gh, but then perform an additional query for that augmented content (which may or may not exist).

[DanRibbens]

Initial thoughts here are that the release notes should not be saved to the db, e.g. what if they're edited on gh? Instead, we should serve the releases dynamically using gh APIs, and remove the releases collection entirely.

This does make sense, though we rarely edit release notes on GH once published.

The original idea for this work of adding releases on the site was to rewrite the GH release notes on the website specifically for end users that may be less technical. It was not as much for devs that implement the features who are on GH already. This faded as we thought about the extra work necessary to rewrite the release notes in this way, even if we used an LLM to generate it which we'd still have to review and publish it.

I'm thinking that Jake is right, but I don't want to slow this work down. There isn't content we'd be adding on the website that couldn't also go in the actual GH release notes. Having a single source of truth is better in the long run. However, if it is easier to move forward with the work as it has been done than to pull from GitHub (rate limiting, SSG rebuild complexity) then we could still have records in the DB for the releases and not be too pedantic about this.