Flipbook-Veröffentlichung in CI/CD mit der FlipLink-CLI automatisieren

Wenn eine PDF in deinem Repo liegt — ein Release-Notes-Deck, ein Produktkatalog, ein Quartalsbericht — dann sollte die Veröffentlichung der Flipbook-Version Teil desselben Builds sein, der die PDF erzeugt. Kein Dashboard, kein manueller Upload, kein "Hat jemand daran gedacht, das Flipbook zu aktualisieren?" Die FlipLink-CLI ist genau dafür gebaut: Sie läuft headless, authentifiziert sich über eine Umgebungsvariable und gibt saubere Exit-Codes zurück, auf die eine Pipeline verzweigen kann.

Diese Anleitung zeigt eine minimale, plattformneutrale CI/CD-Pipeline, die eine PDF baut, das Flipbook erstellt, es veröffentlicht und die Live-URL erfasst.

Warum die Veröffentlichung in CI laufen sollte

Das Dashboard ist großartig für einmalige Uploads. Eine Pipeline ist besser, wenn die Arbeit wiederholbar ist:

• Wiederholbar und nachvollziehbar — dieselben Schritte laufen jedes Mal, protokolliert in deinem CI-Verlauf.
• Kein Dashboard, kein manueller Schritt — niemand muss daran denken, nach einem Release hochzuladen.
• Eine einzige Quelle der Wahrheit — die PDF im Repo ist das, was ausgeliefert wird, sodass das Flipbook nie vom Dokument abweicht.
• Laut scheitern — wenn eine Veröffentlichung fehlschlägt, wird der Build rot, statt stillschweigend ein veraltetes Flipbook auszuliefern.

Das ist Automatisierung im einfachsten Sinne: Die CLI ist dieselbe Engine wie die API, sodass du alles, was du von Hand machen kannst, auch skripten kannst.

Schritt 1: Den API-Schlüssel als CI-Secret speichern

Die CLI liest deinen Schlüssel aus der Umgebungsvariable FLIPLINK_API_KEY in CI (die Auflösungsreihenfolge ist Umgebungsvariable → Konfigurationsdatei → Standard). Einen Schlüssel bekommst du, indem du dich bei go.fliplink.me anmeldest und die Subscription-Seite öffnest.

Füge ihn als Secret bei deinem CI-Anbieter hinzu — committe ihn niemals, gib ihn niemals in Logs aus. Stelle ihn dann dem Job als Umgebungsvariable bereit:

# Provided by your CI's secret store, not hard-coded
export FLIPLINK_API_KEY="$CI_SECRET_FLIPLINK_API_KEY"

Ein schneller Funktionstest, dass die Authentifizierung klappt, bevor du echte Arbeit machst:

fliplink whoami

Wenn der Schlüssel fehlt oder falsch ist, beendet sich dies mit einem Wert ungleich null und deine Pipeline stoppt früh — genau das, was du willst.

Schritt 2: Eine minimale Pipeline

Hier ist eine generische, plattformneutrale Pipeline (Pseudo-YAML — bilde die Schlüssel auf das CI ab, das du verwendest). Für eine release-ausgelöste GitHub-Actions-Version im Speziellen siehe die Anleitung GitHub Actions beim Release.

pipeline:
  publish-flipbook:
    image: node:20
    secrets:
      - FLIPLINK_API_KEY        # injected from the CI secret store
    steps:
      - name: Install the CLI
        run: npm install -g fliplink-cli

      - name: Build the PDF
        run: ./scripts/build-report.sh   # your build that emits ./dist/report.pdf

      - name: Verify auth
        run: fliplink whoami

      - name: Create the flipbook
        run: |
          ID=$(fliplink flipbook create ./dist/report.pdf \
                 --title "Quarterly Report" --name quarterly \
                 --json | jq -r '.ID')
          echo "FLIPBOOK_ID=$ID" >> "$PIPELINE_ENV"

      - name: Publish the flipbook
        run: fliplink flipbook publish "$FLIPBOOK_ID"

      - name: Capture the share URL
        run: |
          URL=$(fliplink flipbook share-link "$FLIPBOOK_ID" \
                  --json | jq -r '.URL')
          echo "Published: $URL"

Der Ablauf besteht aus vier echten Befehlen: die PDF bauen, fliplink flipbook create, fliplink flipbook publish und dann fliplink flipbook share-link. Alles andere ist Klempnerarbeit, die dein CI-Anbieter bereitstellt.

Schritt 3: Die Flipbook-ID und die URL erfassen

Der entscheidende Kniff ist --json. Jeder FlipLink-CLI-Befehl akzeptiert es und gibt rohes JSON aus, das du an jq weiterleitest, um genau das Feld herauszuziehen, das du brauchst:

# Create and grab the new flipbook's ID
ID=$(fliplink flipbook create ./dist/report.pdf \
       --title "Quarterly Report" --name quarterly \
       --json | jq -r '.ID')

# Publish it
fliplink flipbook publish "$ID"

# Grab the public share URL to post in Slack, an email, or a release note
URL=$(fliplink flipbook share-link "$ID" --json | jq -r '.URL')

Gib $ID zwischen den Schritten so weiter, wie dein CI den Zustand teilt — eine Output-Variable, eine Env-Datei oder ein geschriebenes Artefakt. Für weitere jq-Muster — Listen filtern, verschachtelte Felder extrahieren, Tabellen bauen — siehe die CLI mit jq skripten.

🚀

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 4: Bei Exit-Codes sofort abbrechen

Eine Pipeline ist nur so gut wie ihre Fehlerbehandlung. Die CLI gibt dir drei Exit-Codes, auf die du verzweigen kannst:

• 0 — Erfolg
• 1 — Request- oder HTTP-Fehler (schlechtes Netzwerk, 401-Authentifizierungsfehler, zu großer Upload)
• 2 — Anwendungsfehler (die API hat Result: ERROR zurückgegeben, z. B. ein Validierungsproblem)

Die meisten CI-Runner stoppen einen Schritt automatisch bei jedem Exit ungleich null, was in der Regel das ist, was du willst. Wenn du je nach Code unterschiedlich reagieren musst, verzweige explizit:

set -euo pipefail

if fliplink flipbook publish "$ID" --json; then
  echo "Published OK"
else
  code=$?
  if [ "$code" -eq 2 ]; then
    echo "FlipLink rejected the request (application error)" >&2
  else
    echo "Request/HTTP error talking to FlipLink" >&2
  fi
  exit "$code"
fi

Beachte, dass die FlipLink-API Geschäftsfehler als HTTP 200 mit Result: ERROR im Body zurückgibt — die CLI bildet das für dich bereits auf Exit-Code 2 ab, sodass eine saubere Exit-Code-Prüfung ausreicht. Du musst Statuscodes nicht von Hand parsen.

Schritt 5: Bei Erfolg benachrichtigen

Sobald du die URL erfasst hast, besteht der letzte Schritt nur noch darin, jemandem Bescheid zu geben. Die URL ist eine einfache Zeichenkette, also funktioniert jeder Benachrichtiger:

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

curl -X POST "$SLACK_WEBHOOK_URL" \
  -H 'Content-Type: application/json' \
  -d "{\"text\": \"New flipbook published: $URL\"}"

Tausche den curl-Aufruf gegen eine E-Mail, einen GitHub-Kommentar oder einen Eintrag in deinem Changelog — das Muster bleibt gleich. Weil jeder Schritt sofort abbricht, wird diese Benachrichtigung nur ausgelöst, wenn die Veröffentlichung wirklich erfolgreich war.

Fazit

Das ist das gesamte Muster: den Schlüssel als Secret speichern, die CLI installieren, die PDF bauen und dann create → publish → die URL mit --json | jq erfassen, wobei Exit-Codes jeden Schritt absichern. Es ist klein genug, um es in jede Pipeline zu integrieren, und zuverlässig genug, um es zu vergessen — was der Sinn von Automatisierung und Integrationen ist.

Neu bei der CLI? Beginne mit erste Schritte mit der FlipLink-CLI und komme dann zurück, um sie in deinen Build einzubinden.

Weiterführende Lektüre

• FlipLink-CLI-Dokumentation
• Erste Schritte mit der FlipLink-CLI
• GitHub Actions: Ein Flipbook beim Release veröffentlichen
• Die FlipLink-CLI mit jq skripten
• Automatisierung und Integrationen
• FlipLink-API-Referenz