Add a post-MSI smoke test for the frozen DataLab executable

[PierreRaybaut]

Motivation

The current test suite validates DataLab very thoroughly at Python/package level, but it does not fully validate the actual frozen application shipped to Windows users.

Recent packaging fixes are a good example: resources required by SigimaX and DataLab (icons/translations, macro templates, etc.) may be perfectly available in a normal Python environment while being accidentally omitted from the PyInstaller bundle. Such regressions can therefore escape the regular test suite and only appear in the standalone executable.

We should add a lightweight release smoke test for the real Windows artifact.

Proposal

Add a smoke-test step to the build-msi job after the MSI has been built.

Running it after wix build has an important advantage: the release artifacts are already frozen, so the smoke test cannot accidentally modify files that are going to be packaged.

Ideally, the test should exercise the installed MSI, not only dist/DataLab, so that it validates both:

• the PyInstaller bundle itself;
• the WiX packaging of that bundle.

1. Install the MSI into a disposable directory

Install silently into a directory under $RUNNER_TEMP, e.g. with msiexec /qn, overriding INSTALLFOLDER.

2. Start the installed GUI in unattended mode

DataLab already exposes the required command-line primitives:

DataLab.exe --unattended --screenshot --screenshot_path <tmp> --delay 3000 --verbose debug

This is preferable to a simple DataLab.exe --version: --version exits during argument parsing and therefore does not exercise Qt initialization, SigimaX, DLMainWindow, plugins/resources, or post-show initialization.

The GUI smoke test should verify at least:

• the process exits successfully within a short timeout;
• no datalab_error.log is produced in the chosen working directory;
• at least one screenshot is created;
• the process terminates cleanly after the requested delay.

The screenshot is useful as a positive proof that the main window was actually created and rendered, rather than merely that the PyInstaller bootloader started.

3. Add a small frozen-resource probe

GUI startup alone will not necessarily exercise lazily loaded resources. For example, bundled macro templates are loaded only when the macro-template API is used.

A second very small check should therefore run inside the frozen executable, initially using the existing -c support, for example:

DataLab.exe -c "from datalab.gui.macros_templates import list_templates; assert len(list_templates()) >= 3"

The probe should remain deliberately small and only verify packaging-sensitive resources, for example:

• imports of datalab, sigima, sigimax, plotpy, and guidata;
• bundled macro templates are readable;
• embedded FR/EN PDF documentation is present/readable;
• a few critical SigimaX/DataLab resources are accessible;
• optionally, one very lightweight scientific operation that historically depends on dynamically discovered/bundled modules.

The goal is not to run the full test suite again, but to catch failures that only exist in the frozen application.

Suggested CI flow

PyInstaller build
    ↓
Create PyInstaller ZIP
    ↓
Build MSI
    ↓
Install MSI into $RUNNER_TEMP
    ↓
Run installed DataLab.exe in unattended + screenshot mode
    ↓
Run frozen-resource probe
    ↓
Uninstall / cleanup
    ↓
Upload release artifacts

The smoke test should be a release gate: any startup error, timeout, missing screenshot, datalab_error.log, missing critical resource, or non-zero exit status should fail the job.

Possible follow-up: dedicated --smoke-test option

Using -c is sufficient for an initial implementation, but a cleaner long-term solution would be to expose a dedicated internal command such as:

DataLab.exe --smoke-test

It could perform the frozen-resource assertions and return a reliable 0/non-zero exit code. This would make the CI step easier to maintain and provide a reusable diagnostic command for release qualification.

Acceptance criteria

• The MSI is installed silently into a disposable directory in CI.
• The installed DataLab.exe is launched in unattended mode after MSI creation.
• DataLab creates and renders its main window, then exits automatically within a bounded time.
• Startup fails the CI job if datalab_error.log is produced.
• At least one GUI screenshot is produced as evidence of successful rendering.
• A minimal frozen-resource probe checks packaging-sensitive resources such as macro templates and embedded documentation.
• The test does not modify the already-built release artifacts.
• The temporary MSI installation is removed/cleaned up at the end of the job.