GitHub Actions: Bei jedem Release automatisch ein Flipbook erzeugen

Wenn deine Doku, deine Release Notes oder dein Produktkatalog als PDF in deinem Repo liegen, gibt es keinen Grund, das Flipbook von Hand zu veröffentlichen. Mit GitHub Actions und der FlipLink CLI kannst du jedes Mal, wenn du einen Release schneidest, das PDF bauen, daraus ein veröffentlichtes Flipbook machen und die Live-URL direkt zurück an den Release posten — ganz ohne das Dashboard anzufassen.

Das ist die GitHub-native Variante des Flipbook-Publishings per CI/CD. Wenn du einen anderen Runner nutzt (GitLab CI, CircleCI, eine Cron-Box), lassen sich die Schritte sauber übertragen — nur die Form des YAML ändert sich.

Was wir bauen

Ein Workflow, der bei einem veröffentlichten Release ausgelöst wird und:

1. das Repo auscheckt und das PDF baut (oder findet), das du veröffentlichen willst.
2. die FlipLink CLI installiert.
3. aus diesem PDF ein Flipbook erstellt und veröffentlicht und sich dabei mit einem API-Schlüssel authentifiziert, der als Repo-Secret hinterlegt ist.
4. die Live-URL des Flipbooks aus der JSON-Ausgabe erfasst.
5. diese URL zurück an den Release postet, damit dein Team den Link sofort bekommt.

Das ist ein Lehrbuchbeispiel für Automatisierung: Ein Event wird ausgelöst, ein Skript läuft, ein Artefakt geht raus.

Schritt 1 — Speichere deinen API-Schlüssel als Repo-Secret

Füge einen API-Schlüssel niemals direkt in eine Workflow-Datei ein. Workflow-Dateien liegen in deinem Repo — jeder mit Lesezugriff (und jeder Fork) kann sie sehen. Nutze stattdessen ein verschlüsseltes Secret:

1. Melde dich unter https://go.fliplink.me an, öffne die Seite Subscription und kopiere deinen API-Schlüssel.
2. Gehe in deinem GitHub-Repo zu Settings → Secrets and variables → Actions.
3. Klicke auf New repository secret.
4. Benenne es FLIPLINK_API_KEY und füge den Schlüssel als Wert ein.
5. Klicke auf Add secret.

Der Workflow liest es über secrets.FLIPLINK_API_KEY und stellt es der CLI als Umgebungsvariable FLIPLINK_API_KEY zur Verfügung. Die CLI prüft diese Umgebungsvariable automatisch, sodass in CI kein config set-key-Schritt nötig ist.

Schritt 2 — Die Workflow-Datei

Lege .github/workflows/publish-flipbook.yml an:

name: Publish flipbook on release

on:
  release:
    types: [published]

permissions:
  contents: write   # needed to edit the release notes in the last step

jobs:
  flipbook:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repository
        uses: actions/checkout@v4

      - name: Set up Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20

      # Replace this with however you produce the PDF.
      # If the PDF is committed in the repo, you can delete this step.
      - name: Build the PDF
        run: |
          mkdir -p dist
          # e.g. your doc tooling outputs dist/release-notes.pdf
          ls -lh dist/release-notes.pdf

      - name: Install FlipLink CLI
        run: npm install -g fliplink-cli

      - name: Create and publish flipbook
        id: flipbook
        env:
          FLIPLINK_API_KEY: ${{ secrets.FLIPLINK_API_KEY }}
        run: |
          ID=$(fliplink flipbook create ./dist/release-notes.pdf \
            --title "Release ${{ github.event.release.tag_name }}" \
            --name "release-${{ github.event.release.tag_name }}" \
            --json | jq -r '.ID')

          fliplink flipbook publish "$ID"

          URL=$(fliplink flipbook share-link "$ID" --json | jq -r '.URL')

          echo "id=$ID" >> "$GITHUB_OUTPUT"
          echo "url=$URL" >> "$GITHUB_OUTPUT"
          echo "Published flipbook: $URL"

      - name: Comment the URL on the release
        uses: actions/github-script@v7
        with:
          script: |
            const url = "${{ steps.flipbook.outputs.url }}";
            const release = context.payload.release;
            await github.rest.repos.updateRelease({
              owner: context.repo.owner,
              repo: context.repo.repo,
              release_id: release.id,
              body: `${release.body || ""}\n\nFlipbook published: ${url}`
            });

Ein paar Hinweise zum Create-Schritt:

• fliplink flipbook create ./path.pdf lädt das PDF hoch und gibt das neue Flipbook zurück. Mit --json bekommst du die rohe Antwort, und jq -r '.ID' zieht die ID heraus.
• fliplink flipbook publish "$ID" schaltet es live. (Ein Flipbook zu erstellen veröffentlicht es nicht — das Veröffentlichen ist ein separater, expliziter Schritt.)
• fliplink flipbook share-link "$ID" gibt die öffentliche Viewer-URL zurück, die wir auf dieselbe Weise mit jq erfassen.
• Wir schreiben id und url in $GITHUB_OUTPUT, damit spätere Schritte sie als steps.flipbook.outputs.url referenzieren können.

Alles hier nutzt nur dokumentierte CLI-Befehle und das --json-Flag. Wenn du eine Aktion brauchst, die die CLI nicht abdeckt, greif auf die Notlösung fliplink api zurück — siehe die CLI-Doku für den vollständigen Funktionsumfang oder die API-Referenz für jeden Endpunkt.

🚀

FlipLink kostenlos testen

Wandle dein PDF in Sekunden um. Keine Anmeldung, keine Kreditkarte — einfach hochladen und loslegen.

Drop your PDF here or click to browse

Max. 40 MB

Bezahlte Tarife ab $39 erhöhen das auf 150 MB.

Schritt 3 — Die URL zurückposten

Am saubersten lässt sich die URL sichtbar machen, indem du sie an den Release selbst postest. Der actions/github-script-Schritt oben erledigt das. Wenn du lieber die GitHub CLI nutzt (gh ist auf von GitHub gehosteten Runnern vorinstalliert), funktioniert auch dieser Einzeiler:

      - name: Comment via gh
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          gh release view "${{ github.event.release.tag_name }}" \
            --json body --jq '.body' > old-body.txt
          printf '\n\nFlipbook: %s\n' "${{ steps.flipbook.outputs.url }}" >> old-body.txt
          gh release edit "${{ github.event.release.tag_name }}" \
            --notes-file old-body.txt

Das hängt den Flipbook-Link an die Release Notes an, sodass er genau dort sichtbar ist, wo die Leute den Changelog lesen. Wähl einfach das, was zu den Gewohnheiten deines Teams passt — beide lesen die URL aus demselben steps.flipbook.outputs.url.

Hinweise zu Caching und Performance

Ein paar Dinge, die diesen Workflow schnell und vorhersehbar halten:

• Cache npm. Füge cache: npm zum setup-node-Schritt hinzu, wenn dein Repo eine Lockfile hat — das beschleunigt die Installation der CLI und etwaiger PDF-Tools bei wiederholten Läufen.
• Behalte das Rate Limit im Auge. Die FlipLink API erlaubt 300 Anfragen pro Minute pro Schlüssel. Ein einzelner Release veröffentlicht ein Flipbook, du bist also weit von der Obergrenze entfernt — aber wenn du in einem Job auf viele PDFs verteilst, verteile die Aufrufe zeitlich.
• Verzweige bei Fehlern. Die CLI beendet sich bei Erfolg mit 0, bei einem Request-/HTTP-Fehler mit 1 und bei einem Anwendungsfehler mit 2. Da jeder Befehl im run-Block fehlschlagen kann, schlägt der Schritt deutlich fehl, wenn etwas schiefgeht — genau das willst du in CI.
• Halte den Trigger eng. types: [published] bedeutet, dass der Workflow einmal läuft, wenn du tatsächlich einen Release veröffentlichst — nicht bei Entwürfen oder Bearbeitungen vor der Veröffentlichung. Das verhindert versehentliche doppelte Flipbooks.

Fazit

Mit einer Workflow-Datei und einem Repo-Secret liefert jeder Release jetzt ein veröffentlichtes Flipbook aus und postet den Link zurück an dein Team — ganz ohne manuelle Schritte. Von hier aus kannst du einen ganzen Ordner per Batch konvertieren, mit jq reichhaltigere Pipelines skripten oder die Logik in einen KI-Agenten verlagern. Alle Muster bauen auf derselben CLI auf.

Weiterführende Lektüre

• Erste Schritte mit der FlipLink CLI
• Flipbook-Publishing in deiner CI/CD-Pipeline automatisieren
• CLI-Dokumentation
• FlipLink API-Referenz
• Was ist Automatisierung? (Glossar)