GitHub Releases

Verwandle die GitHub-Releases eines Repositorys mit der Quelle githubReleases() in Changelog-Einträge, sodass deine Release Notes dein Changelog sind.

Der integrierte githubReleases()-Adapter verwandelt die Releases eines Repos in ein Changelog: Jedes Release wird zu einem Eintrag vom type: changelog, sodass deine Release Notes dein Changelog sind – du musst nichts doppelt schreiben. Zusammen mit der generierten Changelog-Timeline wird aus jedem veröffentlichten GitHub-Release automatisch ein Changelog-Eintrag.

import { defineConfig } from "blume";
import { filesystem, githubReleases } from "blume/sources";

export default defineConfig({
  content: {
    sources: [
      filesystem({ root: "content" }),
      githubReleases({
        prefix: "changelog",
        owner: "acme",
        repo: "sdk",
        // prereleases: false,  // include prereleases (default off)
        // drafts: false,       // include drafts (needs a write token)
        // limit: 100,          // cap releases, newest-first
      }),
    ],
  },
});

Jedes Release wird automatisch auf die Changelog-Felder abgebildet: Sein Name (oder Tag) wird zum Titel, sein Veröffentlichungsdatum bestimmt die Reihenfolge in der Timeline, der Tag wird zu changelog.version, und Prereleases werden mit Prerelease gekennzeichnet (alle anderen mit Release). Die Release Notes werden als Inhalt des Eintrags gerendert, wobei sich zwei Dinge an ihren Links ändern: Von einem Link, der keine Web-, Mail-, Telefon- oder relative Adresse ist (zum Beispiel eine javascript:-URL), bleibt nur der Linktext übrig, und ein Link zurück auf deine eigene deployment.site wird in einen root-relativen Pfad umgeschrieben, damit er mit Preview-Deployments und deinem Deployment-Basispfad funktioniert. Gib der Quelle ein prefix, damit ihre Release-Seiten unter einer Route wie /changelog/v1-2-0 verschachtelt werden.

Ein privates Repo authentifiziert sich über die Umgebungsvariable GITHUB_TOKEN – dasselbe Token, das auch die anderen GitHub-Features verwenden und das niemals direkt in deine Konfiguration geschrieben wird. Der Adapter deklariert es, sodass ein Build ohne dieses Token eine Warnung ausgibt. Wie jede Remote-Quelle wird es unter .blume/cache/<source>/ gecacht und offline ausgeliefert, wenn die API nicht erreichbar ist. Da ein Changelog nur ergänzend ist, führt ein fehlgeschlagener Abruf ohne Cache (etwa bei einem CI-Build ohne Token) nicht zum Abbruch des Builds, sondern nur zu einem leeren Changelog mit einer Warnung. Setze GITHUB_TOKEN in deinen CI- und Deployment-Umgebungen, damit das Changelog befüllt wird.