GitHub Actions: genera un flipbook automáticamente en cada release

Si tus documentos, notas de versión o catálogo de productos viven como un PDF en tu repo, no hay razón para publicar el flipbook a mano. Con GitHub Actions y el CLI de FlipLink, cada vez que lances un release puedes crear el PDF, convertirlo en un flipbook publicado y poner la URL en vivo directamente en el release — todo sin tocar el panel.

Esta es la versión nativa de GitHub de la publicación de flipbooks con CI/CD. Si usas otro runner (GitLab CI, CircleCI, una máquina con cron), los pasos se trasladan sin problema — solo cambia la forma del YAML.

Lo que vamos a construir

Un flujo de trabajo que se dispara con un release publicado y:

1. Hace checkout del repo y crea (o localiza) el PDF que quieres publicar.
2. Instala el CLI de FlipLink.
3. Crea y publica un flipbook a partir de ese PDF, autenticándose con una clave de API guardada como secreto del repo.
4. Captura la URL en vivo del flipbook desde la salida JSON.
5. Publica esa URL de vuelta en el release para que tu equipo reciba el enlace al instante.

Es un caso de manual de automatización: se dispara un evento, se ejecuta un script, se entrega un artefacto.

Paso 1 — Guarda tu clave de API como un secreto del repo

Nunca pegues una clave de API en un archivo de workflow. Los archivos de workflow viven en tu repo — cualquiera con acceso de lectura (y cada fork) puede verlos. Usa un secreto cifrado en su lugar:

1. Inicia sesión en https://go.fliplink.me, abre la página Subscription y copia tu clave de API.
2. En tu repo de GitHub, ve a Settings → Secrets and variables → Actions.
3. Haz clic en New repository secret.
4. Nómbralo FLIPLINK_API_KEY y pega la clave como valor.
5. Haz clic en Add secret.

El workflow la lee mediante secrets.FLIPLINK_API_KEY y la expone al CLI como la variable de entorno FLIPLINK_API_KEY. El CLI comprueba esa variable de entorno automáticamente, así que no hace falta ningún paso config set-key en CI.

Paso 2 — El archivo de workflow

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

Algunas notas sobre el paso de creación:

• fliplink flipbook create ./path.pdf sube el PDF y devuelve el flipbook nuevo. Con --json obtienes la respuesta en crudo, y jq -r '.ID' extrae el ID.
• fliplink flipbook publish "$ID" lo pone en vivo. (Crear un flipbook no lo publica — publicar es un paso aparte y explícito.)
• fliplink flipbook share-link "$ID" devuelve la URL pública del visor, que capturamos de la misma forma con jq.
• Escribimos id y url en $GITHUB_OUTPUT para que los pasos posteriores puedan referenciarlos como steps.flipbook.outputs.url.

Todo aquí usa solo comandos del CLI documentados y el flag --json. Si necesitas una acción que el CLI no envuelve, baja al recurso de escape fliplink api — consulta los documentos del CLI para conocer toda la superficie, o la referencia de la API para cada endpoint.

🚀

Prueba FlipLink Gratis

Convierte tu PDF en segundos. Sin registro, sin tarjeta de crédito — solo súbelo y listo.

Drop your PDF here or click to browse

Máximo 40MB

Los planes de pago desde $39 lo amplían a 150 MB.

Paso 3 — Publicar la URL de vuelta

La forma más limpia de mostrar la URL es publicarla en el propio release. El paso actions/github-script de arriba hace justo eso. Si prefieres el CLI de GitHub (gh viene preinstalado en los runners alojados por GitHub), esta línea también funciona:

      - 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

Eso añade el enlace del flipbook a las notas de versión, así que queda visible justo donde la gente lee el changelog. Elige el que mejor se adapte a los hábitos de tu equipo — ambos leen la URL desde el mismo steps.flipbook.outputs.url.

Notas sobre caché y rendimiento

Algunas cosas que mantienen este workflow rápido y predecible:

• Cachea npm. Añade cache: npm al paso setup-node si tu repo tiene un lockfile — acelera la instalación del CLI y de cualquier herramienta de PDF en ejecuciones repetidas.
• Vigila el límite de peticiones. La API de FlipLink permite 300 peticiones por minuto por clave. Un solo release publica un flipbook, así que estás muy lejos del tope — pero si te abres en abanico hacia muchos PDF en un mismo job, espacia las llamadas.
• Bifurca según el error. El CLI termina con 0 en caso de éxito, 1 ante un error de petición/HTTP y 2 ante un error de aplicación. Como cada comando del bloque run puede fallar, el paso falla de forma visible si algo sale mal — que es exactamente lo que quieres en CI.
• Mantén el disparador acotado. types: [published] significa que el workflow se ejecuta una sola vez, cuando publicas un release de verdad — no en borradores ni en ediciones previas a la publicación. Eso evita flipbooks duplicados por accidente.

Para terminar

Con un solo archivo de workflow y un secreto del repo, cada release ahora entrega un flipbook publicado y envía el enlace de vuelta a tu equipo — cero pasos manuales. A partir de aquí puedes convertir por lotes una carpeta entera, programar pipelines más ricos con jq o mover la lógica a un agente de IA. Todos los patrones se apoyan en el mismo CLI.

Lecturas relacionadas

• Primeros pasos con el CLI de FlipLink
• Automatiza la publicación de flipbooks en tu pipeline de CI/CD
• Documentación del CLI
• Referencia de la API de FlipLink
• ¿Qué es la automatización? (glosario)