Release changelogs now generate automatically
GitPulse now processes GitHub releases end-to-end, automatically matching each release to its PRs and generating editorial-quality release notes — no manual work required.
GitHub releases have always been a gap in the changelog — the analyzer processed individual PRs and commits, but release-level narratives had to be written by hand. That changes with this PR, the second phase of a three-phase release tracking initiative.
After the existing PR/commit walk completes, the analyzer now fetches recent releases from GitHub via the REST API, matches each release to the PRs that landed in its window using the compare endpoint, and generates a deadpan quip plus 2-3 paragraph release story via LLM. The prompt and output schema were lifted verbatim from the well-tuned implementation in gitsky's web app — the goal is consistent editorial voice across both products.
A key architectural decision: the analyzer computes a hash over the release inputs (tag, sorted story IDs, aggregated stats) and compares it against any existing release file on disk. If the hash matches, the LLM call is skipped entirely — the analyzer is idempotent across runs. This prevents redundant AI calls when nothing has changed while still allowing the system to regenerate if a release's contents evolve.
The release pass is configurable via two new workflow inputs. The releases cap controls how many recent releases to process (default 20, set to 0 to disable entirely). The include-prereleases flag toggles filtering of pre-release drafts. LLM failures are graceful — the system falls back to a simple "Another one shipped." quip rather than bailing out.
The data layer lands in this PR. Phase C will wire up the frontend: components, routes, OG images, JSON-LD, sitemap, and homepage integration.