GitHub Actions : générer un flipbook à chaque release

Si tes docs, tes notes de version ou ton catalogue produit vivent sous forme de PDF dans ton dépôt, il n'y a aucune raison de publier le flipbook à la main. Avec GitHub Actions et la CLI FlipLink, chaque fois que tu publies une release, tu peux créer le PDF, le transformer en flipbook publié et renvoyer l'URL directement sur la release — le tout sans jamais toucher au tableau de bord.

C'est la version native GitHub de la publication de flipbooks en CI/CD. Si tu utilises un autre runner (GitLab CI, CircleCI, une machine cron), les étapes se transposent sans problème — seule la forme du YAML change.

Ce qu'on va construire

Un workflow qui se déclenche sur une release publiée et qui :

1. Récupère le dépôt et crée (ou localise) le PDF que tu veux publier.
2. Installe la CLI FlipLink.
3. Crée et publie un flipbook à partir de ce PDF, en s'authentifiant avec une clé API stockée comme secret du dépôt.
4. Récupère l'URL du flipbook en ligne depuis la sortie JSON.
5. Publie cette URL en commentaire sur la release pour que ton équipe reçoive le lien instantanément.

C'est un cas d'école d'automatisation : un événement se produit, un script s'exécute, un artefact est livré.

Étape 1 — Stocke ta clé API comme secret du dépôt

Ne colle jamais une clé API dans un fichier de workflow. Les fichiers de workflow vivent dans ton dépôt — toute personne ayant un accès en lecture (et chaque fork) peut les voir. Utilise plutôt un secret chiffré :

1. Connecte-toi sur https://go.fliplink.me, ouvre la page Subscription et copie ta clé API.
2. Dans ton dépôt GitHub, va dans Settings → Secrets and variables → Actions.
3. Clique sur New repository secret.
4. Nomme-le FLIPLINK_API_KEY et colle la clé comme valeur.
5. Clique sur Add secret.

Le workflow la lit via secrets.FLIPLINK_API_KEY et l'expose à la CLI comme variable d'environnement FLIPLINK_API_KEY. La CLI vérifie automatiquement cette variable, donc aucune étape config set-key n'est nécessaire en CI.

Étape 2 — Le fichier de workflow

Crée .github/workflows/publish-flipbook.yml :

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}`
            });

Quelques remarques sur l'étape de création :

• fliplink flipbook create ./path.pdf envoie le PDF et renvoie le nouveau flipbook. Avec --json, tu obtiens la réponse brute, et jq -r '.ID' en extrait l'ID.
• fliplink flipbook publish "$ID" le met en ligne. (Créer un flipbook ne le publie pas — la publication est une étape distincte et explicite.)
• fliplink flipbook share-link "$ID" renvoie l'URL publique du lecteur, qu'on récupère de la même façon avec jq.
• On écrit id et url dans $GITHUB_OUTPUT pour que les étapes suivantes puissent y faire référence via steps.flipbook.outputs.url.

Tout ici n'utilise que des commandes CLI documentées et le flag --json. Si tu as besoin d'une action que la CLI n'enrobe pas, descends vers l'échappatoire fliplink api — consulte la doc CLI pour la surface complète, ou la référence API pour chaque endpoint.

🚀

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 3 — Renvoyer l'URL en commentaire

La façon la plus propre de faire remonter l'URL est de la commenter directement sur la release. L'étape actions/github-script ci-dessus s'en charge. Si tu préfères la CLI GitHub (gh est préinstallée sur les runners hébergés par GitHub), ce one-liner fait aussi l'affaire :

      - 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

Cela ajoute le lien du flipbook aux notes de version pour qu'il soit visible juste là où les gens lisent le changelog. Choisis ce qui colle le mieux aux habitudes de ton équipe — les deux lisent l'URL depuis le même steps.flipbook.outputs.url.

Notes sur le cache et la performance

Quelques points qui gardent ce workflow rapide et prévisible :

• Mets npm en cache. Ajoute cache: npm à l'étape setup-node si ton dépôt a un lockfile — ça accélère l'installation de la CLI et de tout outillage PDF sur les exécutions suivantes.
• Surveille la limite de débit. L'API FlipLink autorise 300 requêtes par minute et par clé. Une seule release publie un flipbook, donc tu es loin du plafond — mais si tu déploies en éventail sur de nombreux PDF dans un même job, espace les appels.
• Bifurque en cas d'échec. La CLI sort 0 en cas de succès, 1 sur une erreur de requête/HTTP et 2 sur une erreur applicative. Comme chaque commande du bloc run peut échouer, l'étape échoue bruyamment si quelque chose tourne mal — ce qui est exactement ce que tu veux en CI.
• Garde le déclencheur serré. types: [published] signifie que le workflow s'exécute une seule fois, quand tu publies réellement une release — pas sur les brouillons ni les modifications de pré-publication. Ça évite les flipbooks dupliqués par accident.

Pour conclure

Avec un seul fichier de workflow et un seul secret de dépôt, chaque release livre désormais un flipbook publié et renvoie le lien à ton équipe — zéro étape manuelle. À partir de là, tu peux convertir en lot un dossier entier, scripter des pipelines plus riches avec jq, ou déplacer la logique dans un agent IA. Tous ces schémas reposent sur la même CLI.

Lectures complémentaires

• Premiers pas avec la CLI FlipLink
• Automatiser la publication de flipbooks dans ton pipeline CI/CD
• Documentation de la CLI
• Référence de l'API FlipLink
• Qu'est-ce que l'automatisation ? (glossaire)