👷 add windows CI for MLIR

[DRovara]

Description

This PR adds MLIR CI tests for windows runners.
This is achieved by building MLIR from source so the first execution should take a bit longer.
Afterwards, the cache will be used to store the built versions of MLIR.

This PR contributes to #925

Note: To install a specific version, the runner clones the tag llvmorg-{version}.1.0. It seems that the first release of a new major llvm-project version is typically called {version}.1.0 so this should keep working, but there is no guarantee.

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]

Thanks @DRovara for pushing this 🙏🏼
This was already looking pretty great. I just applied some small finishing touches here and there.

Let's see if CI passes and hope that caching works once this is on the main branch. Waiting two hours for CI certainly is not fun 🙃

I guess my only real question would be if we really want to check out the X.1.0 version of MLIR or whether we would actually like to check out the latest X.Y.Z version, i.e., the latest minor and patch version, which would mirror what the Ubuntu runner is currently doing.

Potentially, we might even opt for doing both in the future, testing the lowest supported LLVM version and the latest one. Similar to how we do testing for the Python package at the moment.
But I guess this is something to keep in mind for the future.

[DRovara]

Thanks @DRovara for pushing this 🙏🏼 This was already looking pretty great. I just applied some small finishing touches here and there.

Let's see if CI passes and hope that caching works once this is on the main branch. Waiting two hours for CI certainly is not fun 🙃

I guess my only real question would be if we really want to check out the X.1.0 version of MLIR or whether we would actually like to check out the latest X.Y.Z version, i.e., the latest minor and patch version, which would mirror what the Ubuntu runner is currently doing.

Potentially, we might even opt for doing both in the future, testing the lowest supported LLVM version and the latest one. Similar to how we do testing for the Python package at the moment. But I guess this is something to keep in mind for the future.

Sure, looks good to me!
I guess you're right about getting the latest minor patch version.
Is there any easy way to do that though or do we manually have to filter for it?

[burgholzer]

Sure, looks good to me! I guess you're right about getting the latest minor patch version. Is there any easy way to do that though or do we manually have to filter for it?

Good question. I do not really know to be honest.
We could simply specify the version for LLVM explicitly down to the patch version for the Windows CI runs. That way, we still need to manually update that once a new version comes out, but we don't need to do any complicated GitHub API parsing and filtering. What do you say?

[DRovara]

Good question. I do not really know to be honest. We could simply specify the version for LLVM explicitly down to the patch version for the Windows CI runs. That way, we still need to manually update that once a new version comes out, but we don't need to do any complicated GitHub API parsing and filtering. What do you say?

I'm not so sure about that. First of all, that could lead to a lot of manual maintenance work, and also that could cause confusion because suddenly after an update, the Linux CI may fail while the one for Windows still passes because we didn't manually update it yet.
Before we do that, I'd rather try to invest half an hour more to see if there's an automated approach for that.

[burgholzer]

I'm not so sure about that. First of all, that could lead to a lot of manual maintenance work, and also that could cause confusion because suddenly after an update, the Linux CI may fail while the one for Windows still passes because we didn't manually update it yet. Before we do that, I'd rather try to invest half an hour more to see if there's an automated approach for that.

Fine with me. And I generally agree with your statement. I just became a bit cautious over the years to demand such extra miles ;o)

[DRovara]

Alright, I'm not sure if this is the most idiomatic/cleanest way to do it (would be cool if you could have another look at it @burgholzer), but this solution seems to work.

I use git ls-remote --tags https://github.com/llvm/llvm-project.git "llvmorg-${{ matrix.llvm-version }}.*", that allows us to check the tags without needing to clone the repo. Then we extract the newest revision for the given version using string manipulation, and use that as key for the cache.

The changes in the build system (maybe the move away from ninja?) also made it so that quantum-opt was no longer found by the check-quantum-opt target. This is because check-quantum-opt calls lit which in turn calls bash.exe which has different system variables than the remaining PowerShell instance. The workaround to that was to define a new script called quantum-opt that's globally accessible and calls the built quantum-opt. Not super clean, but I'm not sure if there's a better solution.

[burgholzer]

Thanks for your work on this @DRovara 🙏🏼
The test execution command looks slightly cryptic to me, but I currently do not have the time myself to search for better ways of runnning the tests and this seems to work.

I think some of these commands would potentially benefit from

shell: bash

because then the syntax is much more uniform between the systems.

Let's tackle this in a potential follow-up PR though and get this in 😌