GitHub Actions: автогенерация флипбука при каждом релизе

Если твоя документация, заметки о релизе или каталог продукции лежат в репозитории в виде PDF, нет смысла публиковать флипбук вручную. С помощью GitHub Actions и FlipLink CLI каждый раз, когда ты выпускаешь релиз, можно собрать PDF, превратить его в опубликованный флипбук и сразу же запостить рабочую ссылку обратно в релиз — и всё это без захода в панель управления.

Это GitHub-нативная версия публикации флипбуков через CI/CD. Если ты используешь другой раннер (GitLab CI, CircleCI, cron-сервер), шаги переносятся без проблем — меняется только форма YAML.

Что мы создаём

Workflow, который срабатывает при публикации релиза и:

1. Делает checkout репозитория и собирает (или находит) PDF, который нужно опубликовать.
2. Устанавливает FlipLink CLI.
3. Создаёт и публикует флипбук из этого PDF, авторизуясь с помощью API-ключа, который хранится как секрет репозитория.
4. Получает рабочую ссылку на флипбук из JSON-вывода.
5. Постит эту ссылку обратно в релиз, чтобы твоя команда сразу её получила.

Это образцовый пример автоматизации: срабатывает событие, выполняется скрипт, отгружается артефакт.

Шаг 1 — Сохрани API-ключ как секрет репозитория

Никогда не вставляй API-ключ прямо в файл workflow. Файлы workflow лежат в репозитории — их видит любой, у кого есть доступ на чтение (и каждый форк). Используй вместо этого зашифрованный секрет:

1. Войди на https://go.fliplink.me, открой страницу Subscription и скопируй свой API-ключ.
2. В своём GitHub-репозитории перейди в Settings → Secrets and variables → Actions.
3. Нажми New repository secret.
4. Назови его FLIPLINK_API_KEY и вставь ключ в поле значения.
5. Нажми Add secret.

Workflow читает его через secrets.FLIPLINK_API_KEY и передаёт в CLI как переменную окружения FLIPLINK_API_KEY. CLI проверяет эту переменную автоматически, поэтому шаг config set-key в CI не нужен.

Шаг 2 — Файл workflow

Создай .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}`
            });

Несколько замечаний по шагу создания:

• fliplink flipbook create ./path.pdf загружает PDF и возвращает новый флипбук. С флагом --json ты получаешь сырой ответ, а jq -r '.ID' вытаскивает из него ID.
• fliplink flipbook publish "$ID" делает флипбук активным. (Создание флипбука не публикует его — публикация это отдельный, явный шаг.)
• fliplink flipbook share-link "$ID" возвращает публичную ссылку на просмотрщик, которую мы получаем тем же способом через jq.
• Мы записываем id и url в $GITHUB_OUTPUT, чтобы последующие шаги могли ссылаться на них как steps.flipbook.outputs.url.

Здесь используются только документированные команды CLI и флаг --json. Если тебе нужно действие, которого нет в обёртке CLI, переходи к запасному варианту fliplink api — смотри документацию CLI, где описана вся поверхность, или справочник по API, где есть каждый эндпоинт.

🚀

Попробуйте FlipLink бесплатно

Преобразуйте PDF за секунды. Без регистрации и кредитной карты — просто загрузите файл.

Drop your PDF here or click to browse

Макс. 40 МБ

На платных тарифах от $39 лимит вырастает до 150 MB.

Шаг 3 — Возврат ссылки в релиз

Самый аккуратный способ показать ссылку — запостить её в самом релизе. Шаг actions/github-script выше как раз это и делает. Если тебе ближе GitHub CLI (gh предустановлен на раннерах, размещённых в GitHub), этот однострочник тоже сработает:

      - 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

Это добавляет ссылку на флипбук в заметки о релизе, чтобы она была видна прямо там, где люди читают changelog. Выбери то, что больше подходит привычкам твоей команды — оба варианта читают ссылку из одного и того же steps.flipbook.outputs.url.

Замечания о кешировании и производительности

Несколько вещей, которые делают этот workflow быстрым и предсказуемым:

• Кешируй npm. Добавь cache: npm к шагу setup-node, если в репозитории есть lock-файл — это ускорит установку CLI и любых PDF-инструментов при повторных запусках.
• Следи за лимитом запросов. API FlipLink допускает 300 запросов в минуту на ключ. Один релиз публикует один флипбук, так что ты и близко не подойдёшь к потолку — но если в одной задаче ты разворачиваешься на множество PDF, разноси вызовы по времени.
• Ветвись при ошибке. CLI завершается с кодом 0 при успехе, 1 при ошибке запроса/HTTP и 2 при ошибке приложения. Поскольку любая команда в блоке run может упасть, шаг падает громко, если что-то идёт не так — а это именно то, что нужно в CI.
• Держи триггер узким. types: [published] означает, что workflow запускается один раз, когда ты действительно публикуешь релиз — а не на черновиках или правках до публикации. Это исключает случайные дубликаты флипбуков.

Подведём итог

С одним файлом workflow и одним секретом репозитория каждый релиз теперь отгружает опубликованный флипбук и постит ссылку обратно твоей команде — ноль ручных шагов. Отсюда можно пакетно конвертировать целую папку, писать более сложные пайплайны с jq или переносить логику в ИИ-агента. Все эти подходы строятся на одном и том же CLI.

Что почитать ещё

• Начало работы с FlipLink CLI
• Автоматизируйте публикацию флипбуков в вашем пайплайне CI/CD
• Документация CLI
• Справочник по API FlipLink
• Что такое автоматизация? (глоссарий)