CI (GitHub Actions, etc.)

La CI (continuous integration) signifie qu’un serveur construit automatiquement votre PDF à chaque push. Vous disposez toujours de la dernière sortie sans compiler localement, et les problèmes de type « ça marche sur ma machine » apparaissent tôt. Pour LaTeX, le choix courant est GitHub Actions : il récupère le dépôt, compile dans un environnement TeX Live et enregistre le PDF obtenu comme artifact.

Pourquoi construire en CI

À chaque push, le document est construit automatiquement dans un environnement TeX Live propre et reproductible. Les avantages : repérer tôt les bogues liés à votre configuration locale, garder le document dans un état connu comme compilable, fournir le dernier PDF aux coauteurs et relecteurs sans TeX installé, et le publier comme release si nécessaire. Le build se définit dans un fichier de workflow (YAML) sous .github/workflows/.

Un workflow GitHub Actions minimal

Placez le YAML suivant sous .github/workflows/build.yml et il fonctionne : actions/checkout récupère la source, xu-cheng/latex-action la compile, et actions/upload-artifact enregistre le PDF. Les versions majeures de GitHub Actions évoluent avec le temps ; cet exemple utilise les lignes majeures courantes en 2026 : checkout v6 et upload-artifact v7.

# .github/workflows/build.yml
name: Build LaTeX
on: [push]
permissions:
  contents: read
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - uses: xu-cheng/latex-action@v4
        with:
          root_file: main.tex
      - uses: actions/upload-artifact@v7
        with:
          name: PDF
          path: main.pdf

xu-cheng/latex-action exige root_file et utilise pdfLaTeX par défaut. Pour changer de moteur, définissez latexmk_use_xelatex: true ou latexmk_use_lualatex: true. Pour les workflows comme upLaTeX + dvipdfmx qui demandent des étapes plus détaillées, validez une .latexmkrc et laissez l’action lire la même configuration que votre build local.

Ce YAML est la forme minimale pour vérifier que le PDF peut être produit. Pour un mémoire ou un article collaboratif, exécutez-le sur push et sur pull_request afin qu’un PDF cassé soit détecté avant la revue. Les versions majeures des actions évoluent ; pour un modèle durable, acceptez les PR de mise à jour des dépendances ou prévoyez une vérification annuelle des README officiels.

L’environnement TeX Live — l’image texlive/texlive

Le build a besoin de TeX Live, et latex-action en embarque un. Pour contrôler finement l’environnement (packages précis, japonais, etc.), vous pouvez utiliser directement l’image Docker texlive/texlive fournie par Island of TeX. Comme latest est reconstruit au fil du temps, épinglez un tag daté ou un tag d’année TeX Live pour les soumissions reproductibles, et gardez latest pour les vérifications quotidiennes. Indiquez-la comme container: du job et lancez latexmk vous-même.

jobs:
  build:
    runs-on: ubuntu-latest
    container: texlive/texlive:latest
    steps:
      - uses: actions/checkout@v6
      - run: latexmk -pdf main.tex
      - uses: actions/upload-artifact@v7
        with:
          name: PDF
          path: main.pdf

Quand la CI échoue, lire le journal

Commencez par classer les échecs de CI en trois catégories : erreur LaTeX, package manquant ou mauvais chemin d’artifact. Si le journal affiche ! LaTeX Error ou Undefined control sequence, déboguez le document. Si File ... not found indique un package TeX Live manquant, ajustez l’image ou l’étape d’installation. Si upload-artifact ne trouve aucun fichier, comparez path: au nom de sortie réel. Quand cela passe localement mais échoue en CI, suspectez des polices, images ou fichiers .bbl générés qui n’existent que sur votre machine.

Le PDF comme artifact — et comme release

• Le PDF enregistré par actions/upload-artifact est téléchargeable depuis la page du workflow run (conservé par exécution).
• Pour distribuer une version publique, vous pouvez joindre le PDF à une GitHub Release (par exemple déclenchée par le push d’un tag).
• Pour le japonais, construisez avec latexmk configuré pour uplatex + dvipdfmx dans le conteneur texlive/texlive.
• Livrez la configuration de build (.latexmkrc, etc.) dans le dépôt afin que le local et la CI suivent les mêmes étapes.
• Pour un workflow de soumission, activez -halt-on-error et conservez les journaux afin de pouvoir remonter aux avertissements.