Automatiser la publication de flipbooks en CI/CD avec la CLI FlipLink

Si un PDF vit dans ton dépôt — une présentation de notes de version, un catalogue produit, un rapport trimestriel — alors la publication de sa version flipbook devrait faire partie du même build qui produit le PDF. Pas de tableau de bord, pas d'envoi manuel, pas de "est-ce que quelqu'un a pensé à mettre à jour le flipbook ?" La CLI FlipLink est conçue exactement pour ça : elle s'exécute en mode headless, s'authentifie depuis une variable d'environnement et renvoie des codes de sortie propres sur lesquels un pipeline peut s'aiguiller.

Ce guide montre un pipeline CI/CD minimal et indépendant de la plateforme qui construit un PDF, crée le flipbook, le publie et récupère l'URL en ligne.

Pourquoi exécuter la publication en CI

Le tableau de bord est idéal pour les envois ponctuels. Un pipeline est préférable quand le travail est répétable :

• Répétable et auditable — les mêmes étapes s'exécutent à chaque fois, consignées dans ton historique CI.
• Pas de tableau de bord, pas d'étape humaine — personne n'a à penser à faire l'envoi après une version.
• Une seule source de vérité — le PDF du dépôt est ce qui part en production, donc le flipbook ne dérive jamais du document.
• Échouer bruyamment — si une publication casse, le build passe au rouge au lieu d'expédier silencieusement un flipbook obsolète.

C'est de l'automatisation au sens le plus simple : la CLI repose sur le même moteur que l'API, donc tout ce que tu peux faire à la main, tu peux le scripter.

Étape 1 : stocker la clé API comme secret CI

La CLI lit ta clé depuis la variable d'environnement FLIPLINK_API_KEY en CI (son ordre de résolution est variable d'environnement → fichier de configuration → valeur par défaut). Obtiens une clé en te connectant sur go.fliplink.me et en ouvrant la page Subscription.

Ajoute-la comme secret dans ton fournisseur CI — ne la commite jamais, ne l'affiche jamais dans les logs. Puis expose-la au job sous forme de variable d'environnement :

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

Une vérification rapide que l'authentification fonctionne avant de passer aux choses sérieuses :

fliplink whoami

Si la clé est absente ou incorrecte, cela renvoie un code non nul et ton pipeline s'arrête tôt — exactement ce que tu veux.

Étape 2 : un pipeline minimal

Voici un pipeline générique et indépendant de la plateforme (pseudo-YAML — mappe les clés sur le CI que tu utilises). Pour une version GitHub Actions déclenchée par une release en particulier, consulte le tutoriel GitHub Actions au moment de la 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"

Le flux se résume à quatre commandes réelles : construire le PDF, fliplink flipbook create, fliplink flipbook publish, puis fliplink flipbook share-link. Tout le reste, c'est de la tuyauterie que ton fournisseur CI met à disposition.

Étape 3 : récupérer l'ID et l'URL du flipbook

L'astuce clé, c'est --json. N'importe quelle commande de la CLI FlipLink l'accepte et affiche du JSON brut, que tu rediriges vers jq pour extraire précisément le champ dont tu as besoin :

# 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')

Transmets $ID d'une étape à l'autre comme ton CI partage l'état — une variable de sortie, un fichier d'environnement ou un artefact écrit. Pour d'autres motifs jq — filtrer des listes, extraire des champs imbriqués, construire des tableaux — consulte scripter la CLI avec jq.

🚀

Essaie FlipLink gratuitement

Convertis ton PDF en quelques secondes. Sans inscription, sans carte bancaire — il suffit de téléverser.

Drop your PDF here or click to browse

Max 40 Mo

Les forfaits payants à partir de $39 font passer cette limite à 150 MB.

Étape 4 : échouer vite grâce aux codes de sortie

Un pipeline ne vaut que ce que vaut sa gestion des erreurs. La CLI te donne trois codes de sortie sur lesquels t'aiguiller :

• 0 — succès
• 1 — erreur de requête ou HTTP (réseau défaillant, échec d'authentification 401, envoi trop volumineux)
• 2 — erreur applicative (l'API a renvoyé Result: ERROR, par exemple un problème de validation)

La plupart des runners CI arrêtent automatiquement une étape sur n'importe quel code de sortie non nul, ce qui est généralement ce que tu veux. Si tu dois réagir différemment selon le code, aiguille-toi explicitement :

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

Note que l'API FlipLink renvoie les erreurs métier sous forme de HTTP 200 avec Result: ERROR dans le corps — la CLI mappe déjà cela vers le code de sortie 2 pour toi, donc une simple vérification du code de sortie suffit. Tu n'as pas à analyser les codes de statut à la main.

Étape 5 : notifier en cas de succès

Une fois l'URL récupérée, la dernière étape consiste simplement à prévenir quelqu'un. L'URL est une simple chaîne de caractères, donc n'importe quel système de notification fonctionne :

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\"}"

Remplace l'appel curl par un e-mail, un commentaire GitHub ou une écriture dans ton changelog — le principe reste le même. Comme chaque étape échoue vite, cette notification ne se déclenche que lorsque la publication a réellement réussi.

Pour conclure

Voilà tout le principe : stocker la clé comme secret, installer la CLI, construire le PDF, puis create → publish → récupérer l'URL avec --json | jq, avec des codes de sortie qui protègent chaque étape. C'est assez compact pour s'intégrer dans n'importe quel pipeline et assez fiable pour qu'on l'oublie — ce qui est tout l'intérêt de l'automatisation et des intégrations.

Tu débutes avec la CLI ? Commence par bien démarrer avec la CLI FlipLink, puis reviens l'intégrer à ton build.

Lectures complémentaires

• Documentation de la CLI FlipLink
• Bien démarrer avec la CLI FlipLink
• GitHub Actions : publier un flipbook au moment de la release
• Scripter la CLI FlipLink avec jq
• Automatisation et intégrations
• Référence de l'API FlipLink