Automate the full release process via GitHub Actions

[PierreRaybaut]

Context

Historically, DataLab releases relied on a local workflow triggered manually on a developer's machine through a series of .bat scripts (PyInstaller build, MSI installer generation, documentation build, graphical asset preparation, etc.). This approach had several limitations:

• Strong dependency on the local environment (third-party tools installed: Inkscape, ImageMagick, LaTeX, WiX Toolset, etc.).
• Poor reproducibility across developers and across releases.
• Manual steps prone to errors (forgotten step, wrong order, diverging local configuration).
• No way to delegate the release to a third party or to an automated process.

Goal

Migrate the entire release procedure to a GitHub Actions CI workflow, so that a full release (PyInstaller binary + MSI installer + multilingual HTML/PDF documentation + associated assets) can be produced end-to-end without any local intervention.

Code signing of the produced artifacts is not in the scope of this issue: it is tracked separately in #328, and was intentionally deferred until this CI workflow is operational (signing is significantly easier to set up in an automated, reproducible environment).

Scope

Commits covered by this work range from tag v1.2.0 to commit d60c87ada6 on main, then continue on the release branch up to commit d78371d791.

Work done

CI workflow setup

• Introduction of GitHub Actions workflows for release and documentation deployment (19f3efab).
• Refactoring of the release workflow into reusable modular sub-workflows, with a dry-run mode (8cf49d64).
• Reusable workflow input adjustments (cast artifact-retention-days to a number — 90bb8135).

Removal of heavy local dependencies

A prerequisite to run the release on a standard GitHub Actions runner was to eliminate third-party tools historically required on local machines:

• Inkscape: pre-generated the WiX bitmaps and icon ahead of time (85eec2f7), then fully refactored resource generation to drop the dependency (d268ae7d).
• ImageMagick: replaced by Pillow for image processing and icon generation (3b92ba23, 08c36b95, 4d025616).

Adjustments to the documentation build strategy

Building the documentation (HTML and PDF, multilingual) required several adaptations to run reliably in CI:

• Install Qt binding in the compile-translations job (a8ba8469).
• Symlink Sigima into the parent directory to resolve literalinclude paths (1853c280).
• Install pytest in the doc-build jobs (sigima.proc.validation imports _pytest — 3b923ba3).
• Rename the loop variable LANG to LNG to avoid Sphinx locale errors (ab4ab046).
• Add imagemagick and librsvg2-bin to build dependencies, and include the imgconverter extension in Sphinx (b21b5bfb).
• Switch the PDF build from pdflatex to xelatex for better Unicode support (1d7146fd), then simplify the ucharclasses usage (55db7c09).
• Allow LaTeX warnings in CI for compatibility with local builds (ce5e6edf).
• Use a lowercase filename for the generated PDF (ccf18f25).
• Add the needspace package to prevent orphan section headings (a97043df).
• Add the tabularcolumns directive for better table formatting (85d66934).
• Pin the WixToolset.UI.wixext extension version in the workflow (d2fcedd3).
• Update the doc build configuration and improve table formatting (1d141c97).
• Fix the main PDF generation logic (8696408a).
• Final adjustment of table column widths (d60c87ad).

Finalisation on the release branch

• Version bump to 1.2.1 (75de6750) along with related functional fixes (signal linear calibration, ROI editor, geometry_results test).
• Update of graphics resources and localisation files for the documentation and UI (c1ad38d7, 9844319f).
• Reorganisation of the documentation tasks in tasks.json (6bae1271, 0d49aa38).
• Clean xelatex PDF build (emojis, warnings, modindex — 5dc34c40).
• Improved handling of LaTeX font transitions (b16caabd).
• Final adjustment of table column widths for PDF output (d78371d7).

Benefits

• Reproducibility: every release is produced in a controlled, identical environment.
• Traceability: every release is tied to a CI run whose logs, artifacts and environment are archived.
• Delegation: a release can be triggered by any maintainer with the right permissions, with no specific local setup.
• Mandatory prerequisite for automated signing of the binary and the MSI installer (tracked in a separate issue).

Acceptance criteria

• A GitHub Actions workflow produces the PyInstaller binary, the MSI installer and the multilingual HTML/PDF documentation.
• No Inkscape or ImageMagick dependency remains on the release path.
• The workflow can be run in dry-run mode without publishing.
• The PDF documentation is built cleanly via xelatex (Unicode, emojis, table layout).
• Release v1.2.1 is fully produced by the new CI workflow.