Refactor CI for Windows x64

[csukuangfj]

Summary by CodeRabbit

• New Features

  • Extended Windows x64 builds to support multiple configurations: Debug, RelWithDebInfo, and MinSizeRel variants alongside Release.

• Chores

  • Consolidated Windows build workflows for improved maintainability.
  • Simplified build configuration logic.

[gemini-code-assist]

Summary of Changes

Hello @csukuangfj, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refactors the continuous integration (CI) setup for Windows x64 by streamlining how ONNX Runtime static libraries are configured and downloaded. The changes aim to improve the maintainability and flexibility of the build system by centralizing configuration logic and ensuring consistent support across various build types, thereby reducing redundancy and potential for errors.

Highlights

• Consolidation of ONNX Runtime Static Library Configuration: The logic for handling ONNX Runtime static libraries on Windows x64 has been consolidated into a single CMake file, cmake/onnxruntime-win-x64-static.cmake, eliminating the need for a separate debug-specific configuration.
• Removal of Redundant CMake File: The file cmake/onnxruntime-win-x64-static-debug.cmake has been removed, as its functionality is now integrated into the unified cmake/onnxruntime-win-x64-static.cmake.
• Enhanced Build Type Support: The cmake/onnxruntime-win-x64-static.cmake file now dynamically supports all standard CMake build types (Release, Debug, RelWithDebInfo, MinSizeRel) by incorporating the build type into the selection of SHA256 hashes and download URLs for ONNX Runtime libraries.
• Simplified Inclusion Logic: The main cmake/onnxruntime.cmake file has been updated to unconditionally include onnxruntime-win-x64-static.cmake for Windows x64 static library builds, simplifying the overall build system logic.

Ignored Files

• Ignored by pattern: .github/workflows/** (2)
  • .github/workflows/windows-x64-debug.yaml
  • .github/workflows/windows-x64.yaml

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[coderabbitai]

Caution

Review failed

The pull request is closed.

📝 Walkthrough

Walkthrough

This pull request consolidates Windows x64 build infrastructure by removing a debug-specific workflow file, expanding the main Windows workflow to support multiple build types (Release, Debug, RelWithDebInfo, MinSizeRel), and refactoring CMake logic to handle per-build-type ONNX Runtime hash mappings and artifact management.

Changes

Cohort / File(s)	Summary
Windows Workflow Updates .github/workflows/windows-x64-debug.yaml, .github/workflows/windows-x64.yaml	Deleted debug-specific workflow and expanded main workflow with matrix-based build-type support (Release, Debug, RelWithDebInfo, MinSizeRel). Updated artifact naming, CMake configuration, and test execution to accommodate per-build-type binaries. Removed several test script triggers from matrix.
ONNXRuntime CMake Consolidation cmake/onnxruntime-win-x64-static-debug.cmake	Deleted dedicated debug configuration file, consolidating multi-build-type handling into the static variant.
ONNXRuntime Static CMake Enhancement cmake/onnxruntime-win-x64-static.cmake	Expanded build-type validation to support Release, Debug, RelWithDebInfo, and MinSizeRel. Introduced per-build-type hash variables (ONNXRUNTIME_HASH_MT/MD_*) and dynamic onnxruntime_filename with per-build-type URL construction.
ONNXRuntime CMake Validation cmake/onnxruntime-win-x64.cmake	Updated CMAKE_BUILD_TYPE validation to use regex pattern matching instead of individual equality checks.
ONNXRuntime Orchestration cmake/onnxruntime.cmake	Simplified Windows x64 static ONNX Runtime inclusion by removing debug-specific branching logic and unconditionally using the static variant configuration.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Possibly related PRs

• Fix MSVC CRT for Windows x64 shared build. #3114: Directly related—introduces identical per-CRT and per-build-type hash handling and dynamic filename/URL construction for Windows x64 ONNXRuntime.
• Support MD and MT MSVC runtime libraries (CRT) for Windows x64 static build #3111: Related—modifies Windows x64 ONNX Runtime CMake and CI workflows to support multiple MSVC CRT/build-type variants.
• Fix building for onnxruntime >= 1.11.0 #2981: Related—modifies cmake/onnxruntime.cmake for ONNXRuntime lib file handling and build-type logic.

Suggested labels

size:M

Poem

🐰 Four build types now unified,
Where debug paths were mystified,
One workflow matrix reigns supreme,
With hashes per-build-type scheme,
The rabbit's work, both clean and bright!

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

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.}

[gemini-code-assist]

Code Review

This pull request refactors the CMake scripts for building on Windows x64, consolidating the logic for different build types into a single file and removing a redundant one. This simplifies the overall build process, reduces code duplication, and improves maintainability. The changes also enhance readability and make the scripts more robust on Windows by using appropriate environment variables. Overall, this is an excellent refactoring. I have one minor suggestion to further improve Windows compatibility.

[gemini-code-assist]

For better compatibility on Windows, it's recommended to use $ENV{USERPROFILE} instead of $ENV{HOME} to refer to the user's home directory. $ENV{HOME} is not a standard environment variable on Windows, whereas $ENV{USERPROFILE} is. Using the standard variable will make the script more robust across different Windows environments.

  $ENV{USERPROFILE}/Downloads/${onnxruntime_filename}