Continuous Integration
Every change to MNE-CPP is automatically built, tested, and — for releases — packaged across Windows, Linux, and macOS before it reaches users. The CI system runs on GitHub Actions and is organized around the Main – Staging – Feature branch model.
Pull requests cannot be merged until all platform jobs pass. Development builds are published from staging on pushes that touch the build or packaging, and nightly; stable release binaries are created when a version tag (v*) is pushed on main.
Guides
- GitHub Actions — Workflow overview, the pull-request, staging, and release pipelines, secrets, and how to add or modify workflows.
- Unit Testing — How to write and run unit tests using Qt Test, including test structure, reference data, and naming conventions.
- Deployment — How Qt dependencies are bundled on each platform using
windeployqt,linuxdeployqt, andmacdeployqt. - Release Guide — Branch model, versioning, and the step-by-step process for creating a new stable release.
At a Glance
| Branch / Event | Workflow | What Happens |
|---|---|---|
Pull request → staging or main | pull-request.yml | Build + tests on all platforms (max Qt), min Qt on Linux, WebAssembly build |
Push to staging | staging.yml | Tests with coverage checks (min + max Qt, all platforms), quality and docs gates, WebAssembly build |
| Push touching the build, nightly, manual | staging.yml | Also dev release binaries, dev website + Doxygen |
Push to main | main.yml | Tests, stable website + Doxygen deployment |
Tag v* on main | main.yml | Full stable release: platform binaries, installers, WebAssembly |
Push to wasm | wasmtest.yml | WebAssembly build deployed to GitHub Pages |
| Timer (every 2 days) | coverity.yml | Coverity static code analysis |
Contributors should follow the contribution workflow to ensure their changes pass all CI checks before requesting a review.