Home Blog CI/CD for a print artifact: one principle, two projects
Blog

CI/CD for a print artifact: one principle, two projects

Olivier Carrère 2 min read
View as Markdown
On this page

Why run GitHub Actions CI/CD pipelines for PDF print artifacts? Building press-ready PDFs locally relies on developer workstation state: different TeX Live releases alter line hyphenation, paragraph breaking, and page counts.

Enters continuous integration for print. Running pinned TeX Live containers inside GitHub Actions runners produces deterministic press-ready PDFs on every commit.

An exhausted typesetter sits at a workbench surrounded by thousands of identical printed copies, with a tiny typo circled in an open book. The vast stacks of copies emphasize the cost of discovering an error after printing.
Without CI/CD, a tiny typo can mean an expensive reprint of thousands of copies.

Environment variability hazards

Local build environments introduce silent compilation drift:

  • TeX Live version discrepancies: Differing package versions shift hyphenation matrices across machines.
  • Font metric shifts: Local font updates alter character widths and paragraph pagination.
  • Unverified local builds: Relying on contributor workstation builds risks sending unverified binaries to print shops.

Continuous integration solves environment drift by compiling source files inside isolated, pinned Linux containers.

Multi-author book builds

A three-volume book project compiles PDF output on every commit to main:

Pinning the pipeline to TeX Live 2023 locks layout rendering rules across years of maintenance edits.

Automated poster publication

An annual planning poster pipeline builds six distinct PDF/X-4 variants from a single YAML data edit:

  1. YAML pull request: Non-technical contributors edit planning/events-*.yaml via GitHub web interfaces.
  2. Automated semantic diff comments: On every pull request affecting planning/, the CI workflow executes diff_saison.py and posts a sticky comment comparing dates, prices, and events between seasons so reviewers inspect business changes rather than raw syntax diffs.
  3. Automated CMYK conversion: prepare_images.py converts embedded sRGB images to FOGRA39 CMYK.
  4. Preflight verification: preflight.py verifies resolution, font embedding, and PDF/X-4 conformance.

Provenance and traceability

Both build architectures embed compilation metadata directly inside generated deliverables. Book colophons record Git commit hashes, hostnames, and LuaTeX engine versions. PDF/X-4 files embed XMP build metadata for press auditing.

Running build environments in CI replaces workstation guesswork with deterministic compilation guarantees. The next step is publishing containerized Docker build images to Docker Hub for identical offline local reproduction.

External sources

Hero image: “The Binding Machine” by Ms. Tharpe, licensed under CC BY 2.0.

Follow Olivier Carrère on LinkedIn

Continuous writing on docs-as-code, DITA XML, YAML, and AI-assisted documentation pipelines.

Follow