GitHub Actions: genereer automatisch een flipbook bij elke release

Als je documentatie, release notes of productcatalogus als PDF in je repo staat, is er geen reden om het flipbook met de hand te publiceren. Met GitHub Actions en de FlipLink CLI kun je elke keer dat je een release uitbrengt de PDF bouwen, er een gepubliceerd flipbook van maken en de live-URL meteen terugzetten op de release — allemaal zonder het dashboard aan te raken.

Dit is de GitHub-eigen variant van flipbooks publiceren via CI/CD. Gebruik je een andere runner (GitLab CI, CircleCI, een cron-machine)? Dan zijn de stappen prima over te zetten — alleen de vorm van de YAML verandert.

Wat we gaan bouwen

Een workflow die wordt geactiveerd bij een gepubliceerde release en:

1. De repo uitcheckt en de PDF die je wilt publiceren bouwt (of opzoekt).
2. De FlipLink CLI installeert.
3. Een flipbook van die PDF aanmaakt en publiceert, met authenticatie via een API-sleutel die als repo-secret is opgeslagen.
4. De live-flipbook-URL uit de JSON-output haalt.
5. Die URL terugplaatst op de release, zodat je team de link meteen krijgt.

Het is een schoolvoorbeeld van automatisering: er treedt een gebeurtenis op, een script draait en een artifact wordt verzonden.

Stap 1 — Sla je API-sleutel op als repo-secret

Plak nooit een API-sleutel in een workflowbestand. Workflowbestanden staan in je repo — iedereen met leestoegang (en elke fork) kan ze zien. Gebruik in plaats daarvan een versleuteld secret:

1. Log in op https://go.fliplink.me, open de pagina Subscription en kopieer je API-sleutel.
2. Ga in je GitHub-repo naar Settings → Secrets and variables → Actions.
3. Klik op New repository secret.
4. Geef het de naam FLIPLINK_API_KEY en plak de sleutel als waarde.
5. Klik op Add secret.

De workflow leest het uit via secrets.FLIPLINK_API_KEY en stelt het aan de CLI beschikbaar als de omgevingsvariabele FLIPLINK_API_KEY. De CLI controleert die env-variabele automatisch, dus er is geen config set-key-stap nodig in CI.

Stap 2 — Het workflowbestand

Maak .github/workflows/publish-flipbook.yml aan:

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

Een paar opmerkingen over de create-stap:

• fliplink flipbook create ./path.pdf uploadt de PDF en geeft het nieuwe flipbook terug. Met --json krijg je de ruwe respons, en jq -r '.ID' haalt de ID eruit.
• fliplink flipbook publish "$ID" zet het live. (Een flipbook aanmaken publiceert het niet — publiceren is een aparte, expliciete stap.)
• fliplink flipbook share-link "$ID" geeft de publieke viewer-URL terug, die we op dezelfde manier met jq ophalen.
• We schrijven id en url naar $GITHUB_OUTPUT, zodat latere stappen ernaar kunnen verwijzen als steps.flipbook.outputs.url.

Alles hier gebruikt alleen gedocumenteerde CLI-commando's en de --json-vlag. Heb je een actie nodig die de CLI niet afdekt? Val dan terug op de fliplink api-noodoplossing — bekijk de CLI-documentatie voor het volledige aanbod, of de API-referentie voor elk endpoint.

🚀

Probeer FlipLink Gratis

Converteer je PDF in seconden. Geen registratie, geen creditcard — gewoon uploaden en starten.

Drop your PDF here or click to browse

Max. 40MB

Met een betaald abonnement vanaf $39 verhoog je dit naar 150 MB.

Stap 3 — De URL terugplaatsen

De netste manier om de URL te tonen is om hem op de release zelf te plaatsen. De actions/github-script-stap hierboven doet dat. Werk je liever met de GitHub CLI (gh staat standaard op door GitHub gehoste runners)? Dan werkt deze one-liner ook:

      - 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

Dat zet de flipbook-link onder aan de release notes, zodat hij precies daar zichtbaar is waar mensen de changelog lezen. Kies wat het beste bij de werkwijze van je team past — beide lezen de URL uit dezelfde steps.flipbook.outputs.url.

Opmerkingen over caching en prestaties

Een paar dingen die deze workflow snel en voorspelbaar houden:

• Cache npm. Voeg cache: npm toe aan de setup-node-stap als je repo een lockfile heeft — dat versnelt het installeren van de CLI en eventuele PDF-tooling bij herhaalde runs.
• Let op de rate limit. De FlipLink API staat 300 requests per minuut per sleutel toe. Eén release publiceert één flipbook, dus je zit nergens in de buurt van het plafond — maar als je in één job naar veel PDF's uitwaaiert, spreid de calls dan.
• Vertak bij een fout. De CLI sluit af met 0 bij succes, 1 bij een request-/HTTP-fout en 2 bij een applicatiefout. Omdat elk commando in het run-blok kan mislukken, valt de stap luid uit als er iets misgaat — precies wat je in CI wilt.
• Houd de trigger strak. types: [published] betekent dat de workflow één keer draait, namelijk wanneer je echt een release publiceert — niet bij concepten of pre-publicatiebewerkingen. Zo voorkom je per ongeluk dubbele flipbooks.

Tot slot

Met één workflowbestand en één repo-secret levert elke release nu een gepubliceerd flipbook op en plaatst de link terug naar je team — zonder handmatige stappen. Vanaf hier kun je een hele map in bulk omzetten, rijkere pipelines scripten met jq, of de logica naar een AI-agent verplaatsen. De patronen bouwen allemaal voort op dezelfde CLI.

Verder lezen

• Aan de slag met de FlipLink CLI
• Automatiseer flipbook-publicatie in je CI/CD-pijplijn
• CLI-documentatie
• FlipLink API-referentie
• Wat is automatisering? (woordenlijst)