🚸 Adapt C++ workflows to require CMake presets

[denialhaag]

Description

This PR adapts the C++ workflows to require CMake presets.

Fixes #352

Checklist

• The pull request only contains commits that are focused and relevant to this change.
• I have added appropriate tests that cover the new/changed functionality.
• I have updated the documentation to reflect these changes.
• I have added entries to the changelog for any noteworthy additions, changes, fixes, or removals.
• I have added migration instructions to the upgrade guide (if needed).
• The changes follow the project's style guidelines and introduce no new warnings.
• The changes are fully tested and pass the CI checks.
• I have reviewed my own code changes.

[burgholzer]

I really like how clean this has become!
This is only missing a changelog entry, and upgrade guide note, and the actual release preparation. I think it would be fine to already do that as part of this PR.

The title could also use an update since it is now no longer just support, but we switched to CMake presets for the C++ workflows.
Everyone using the C++ workflows now has to provide such presets.
Is that enough cause for this to actually be a major version?

[denialhaag]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[denialhaag]

This is only missing a changelog entry, and upgrade guide note, and the actual release preparation. I think it would be fine to already do that as part of this PR.

Done.

The title could also use an update since it is now no longer just support, but we switched to CMake presets for the C++ workflows. Everyone using the C++ workflows now has to provide such presets. Is that enough cause for this to actually be a major version?

Also done. I agree that it makes sense to make this a major release. 😌

[coderabbitai]

📝 Walkthrough

Summary by CodeRabbit

• Breaking Changes

  • C++ reusable workflows (test, coverage, linter) now require CMake presets for configuration instead of separate build-type and cmake-args inputs.

• Documentation

  • Comprehensive migration guide added with examples for updating to preset-based C++ workflows and new Windows MLIR debug option.

Walkthrough

This PR migrates reusable C++ GitHub Actions workflows to require CMake presets (preset-name), removes cmake-args/config inputs, switches configure/build/test to cmake --preset/cmake --build --preset/ctest --preset, installs and exports lit as LIT_BIN for MLIR runs, and updates CHANGELOG and UPGRADING for v2.0.0.

Changes

CMake Presets Migration for Reusable C++ Workflows

Layer / File(s)	Summary
Workflow input interface refactor .github/workflows/reusable-cpp-coverage.yml, .github/workflows/reusable-cpp-linter.yml, .github/workflows/reusable-cpp-tests-macos.yml, .github/workflows/reusable-cpp-tests-ubuntu.yml, .github/workflows/reusable-cpp-tests-windows.yml	Removes config (build type) and cmake-args inputs where present; adds required preset-name to test workflows and mlir-debug boolean for Windows; updates concurrency groups and job display names to use preset-name.
Preset-based build execution and MLIR/lit wiring .github/workflows/reusable-cpp-coverage.yml, .github/workflows/reusable-cpp-linter.yml, .github/workflows/reusable-cpp-tests-macos.yml, .github/workflows/reusable-cpp-tests-ubuntu.yml, .github/workflows/reusable-cpp-tests-windows.yml	CMake configure/build/test steps use presets (cmake --preset, cmake --build --preset, ctest --preset); MLIR lit is installed via uv pip install lit and its path exported as LIT_BIN into GITHUB_ENV.
Release documentation and upgrade guide CHANGELOG.md, UPGRADING.md	Adds 2.0.0 release notes and a 2.0.0 UPGRADING section documenting breaking changes to workflow inputs, new preset-name and mlir-debug flag, and provides an example CMakePresets.json.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• munich-quantum-toolkit/workflows#295: Prior PR updating lit installation and MLIR/lit wiring in reusable C++ workflows.
• munich-quantum-toolkit/workflows#270: Earlier changes to MLIR setup inputs and plumbing that this PR further refactors.
• munich-quantum-toolkit/workflows#335: Related edits to Windows tests workflow MLIR/debug handling.

Suggested labels

continuous integration, documentation, enhancement

Suggested reviewers

• burgholzer

Poem

🐰 I hopped through YAML, snug and spry,

Presets now lead builds, no more why,
Lit finds its home in GITHUB_ENV,
Jobs run tidy, presets begin,
A tiny hop for CI, a joyful sigh.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Adapt C++ workflows to require CMake presets' clearly describes the main change in the PR, which is migrating workflows from manual CMake arguments to preset-based configuration.
Description check	✅ Passed	The PR description includes a summary of changes, fixes a linked issue (#352), and covers most checklist items. Minor note: test and documentation update items are struck through as not applicable.
Linked Issues check	✅ Passed	The PR fully addresses issue #352 by implementing CMake preset support across all C++ reusable workflows (coverage, linter, tests on macOS/Ubuntu/Windows), removing manual cmake-args inputs, and adding preset-name inputs.
Out of Scope Changes check	✅ Passed	All changes are directly related to implementing CMake preset support. Documentation updates (CHANGELOG.md, UPGRADING.md) and the new mlir-debug flag for Windows are all in scope for this preset migration.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch cmake-presets

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 5

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/reusable-cpp-linter.yml:
- Around line 160-161: The "Build" step currently always runs the cmake build
command (cmake --build --preset lint) which ignores the workflow's build gating;
update the "Build" step to respect the reusable workflow input by adding a
conditional (e.g., if: ${{ inputs.build-project == 'true' }} or the repository's
equivalent) so the step only executes when build-project is enabled, keeping the
step name "Build" and the build command unchanged.

In @.github/workflows/reusable-cpp-tests-macos.yml:
- Around line 44-47: The workflow input "preset-name" is currently optional
because it has default: ""; make it required at the workflow boundary by
removing the default and adding required: true to the input definition so
callers must supply it; keep the existing description and type fields and ensure
the input block for preset-name contains description, type: string, and
required: true.

In @.github/workflows/reusable-cpp-tests-ubuntu.yml:
- Around line 44-47: The workflow input "preset-name" currently has a default
empty string which allows invalid runtime calls; update the "preset-name" input
definition (symbol: preset-name) to make it required by removing the default and
adding required: true so the workflow fails fast on missing value and prevents
executing cmake --preset "".

In @.github/workflows/reusable-cpp-tests-windows.yml:
- Around line 42-45: The input "preset-name" is currently optional due to
`default: ""`; make it required so callers fail at validation time by removing
the `default` key (or its empty value) and adding `required: true` under the
`preset-name` input definition in the workflow; update the `description`/`type`
block for `preset-name` and ensure `required: true` is present so workflow-call
validation enforces the input.
- Line 84: Replace the brittle substring check that sets the debug output
("debug: ${{ contains(inputs.preset-name, 'debug') }}") with an explicit,
canonical flag or deterministic mapping: add or use a dedicated input like
inputs.mlir-debug (boolean) or normalize and compare inputs.preset-name against
a whitelist of debug preset names (e.g., toLower(inputs.preset-name) == 'debug'
or membership check against known debug presets), and then set debug using that
explicit input (e.g., "debug: ${{ inputs.mlir-debug }}" or the whitelist
expression) so MLIR debug mode is not inferred by substring matching.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: f12b951c-4d0c-4592-b161-1e95abe96a8d

📥 Commits

Reviewing files that changed from the base of the PR and between b078b5f and e63998b.

📒 Files selected for processing (7)

• .github/workflows/reusable-cpp-coverage.yml
• .github/workflows/reusable-cpp-linter.yml
• .github/workflows/reusable-cpp-tests-macos.yml
• .github/workflows/reusable-cpp-tests-ubuntu.yml
• .github/workflows/reusable-cpp-tests-windows.yml
• CHANGELOG.md
• UPGRADING.md

[denialhaag]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[burgholzer]

Looks almost ready to go in.

What I am wondering as well: Since this is going to be a major release now; are there any other things that we would want to get in that would be considered majorly breaking?

[denialhaag]

Since this is going to be a major release now; are there any other things that we would want to get in that would be considered majorly breaking?

I honestly cannot think of anything. 🤔

[burgholzer]

Nice! One more suggestion to go, then this can go in and we can release 😌
Probably worth running renovate once more before the release, but that should be it then.

[denialhaag]

@coderabbitai review

[coderabbitai]

✅ Actions performed

Review triggered.

Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@UPGRADING.md`:
- Line 12: The documentation mentions the wrong flag name; update UPGRADING.md
to use the actual workflow input name `mlir-debug` (to match the input in
reusable-cpp-tests-windows.yml) so examples and migration notes reference
`mlir-debug` instead of `debug-mlir`, ensuring consistency between UPGRADING.md
and the reusable-cpp-tests-windows.yml workflow input.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: aa256d2d-f080-4cc2-b265-f9234054c683

📥 Commits

Reviewing files that changed from the base of the PR and between e63998b and 15296fb.

📒 Files selected for processing (6)

• .github/workflows/reusable-cpp-linter.yml
• .github/workflows/reusable-cpp-tests-macos.yml
• .github/workflows/reusable-cpp-tests-ubuntu.yml
• .github/workflows/reusable-cpp-tests-windows.yml
• CHANGELOG.md
• UPGRADING.md

CodeRabbit did not approve the PR after resolving its final comment