Build for Windows and Linux ARM64 in CI

[AFCMS]

• Fix the duplicated workflow runs on PRs (pr + branch)
• Bump egor-tensin/setup-clang from v1 to v2
• Bump actions/upload-artifact from v4 to v7
• Bump CMake used on Linux to v4.4.2 (latest)
• Implement Vector4's dot for ARM64
• Build the project for ARM64 on Linux and Windows native GitHub Action runners

Summary by CodeRabbit

• New Features

  • Added ARM64 support for Vector4 dot-product calculations, improving compatibility on ARM-based systems.

• Build & Platform Support

  • Expanded Linux and Windows builds to support both x64 and ARM64 architectures.
  • Added architecture-specific build artifacts for easier platform selection.
  • Updated build tooling and parallelization to improve build and test execution.

[coderabbitai]

Warning

Review limit reached

@AFCMS, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 45 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 33bd61c1-335b-4b1f-b79e-61bd43d05129

📥 Commits

Reviewing files that changed from the base of the PR and between 3baccc6 and ee678b3.

📒 Files selected for processing (3)

• .github/workflows/linux_build.yml
• .github/workflows/windows_build.yml
• Engine/cpp/Runtime/Core/Math/Vector4.cppm

📝 Walkthrough

Walkthrough

The CI workflows now build Linux and Windows targets for x64 and arm64. Architecture-specific toolchains, caches, artifacts, and parallelism are configured. ARM64 Vector4::dot now uses NEON intrinsics.

Changes

Architecture matrix CI

Layer / File(s)	Summary
Linux architecture matrix builds .github/workflows/linux_build.yml	The workflow builds x64 and arm64 targets with architecture-specific runners, CMake binaries, caches, and artifacts.
Windows architecture matrix builds .github/workflows/windows_build.yml	The workflow builds x64 and arm64 targets with architecture-specific runners, compiler targets, caches, processor counts, and artifacts.

ARM64 vector support

Layer / File(s)	Summary
NEON dot product implementation Engine/cpp/Runtime/Core/Math/Vector4.cppm	The ARM64 Vector4::dot path uses NEON loads, multiplication, and horizontal summation.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Possibly related PRs

• Redot-Engine/DraconicEngine#25: Both changes update Linux CI build, cache, and artifact configuration.
• Redot-Engine/DraconicEngine#55: This change extends the Windows and Linux CI workflows introduced there.

Suggested reviewers: shakai-dev

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: adding Windows and Linux ARM64 CI builds.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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

[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 @.github/workflows/linux_build.yml:
- Around line 40-43: Validate each downloaded CMake archive before extraction in
the workflow’s CMake setup step: download the official cmake-4.4.2-SHA-256.txt
file, verify the architecture-specific archive against its listed SHA-256
checksum, and only run tar -xzf after verification succeeds for both
archive-download paths.

🪄 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: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: dd8ebdf9-f254-47d9-a0e4-000166ca9d7f

📥 Commits

Reviewing files that changed from the base of the PR and between feebd2f and 3baccc6.

📒 Files selected for processing (3)

• .github/workflows/linux_build.yml
• .github/workflows/windows_build.yml
• Engine/cpp/Runtime/Core/Math/Vector4.cppm

[JoltedJon]

I believe it was intentional for CI to run on every branch so that every PR has it run, but I am not exactly sure how that parameter works. Is it what branch the PR is trying to merge into? If so then your change is probably good

[Shakai-Dev]

I believe it was intentional for CI to run on every branch so that every PR has it run, but I am not exactly sure how that parameter works. Is it what branch the PR is trying to merge into? If so then your change is probably good

Yea, it's the branch it's trying to merge into. The changes lgtm & can be merged

[AFCMS]

I believe it was intentional for CI to run on every branch so that every PR has it run, but I am not exactly sure how that parameter works. Is it what branch the PR is trying to merge into? If so then your change is probably good

The PR trigger makes the workflow run regardless of target branch. Using a wildcard for the branch trigger makes the workflow run regardless of the existence of a PR.

To just remove the duplicated runs but still run on every branch, the wildcard could be kept and the PR trigger removed entirely, but usually main branch + PRs are sufficient.

[Arctis-Fireblight]

I believe it was intentional for CI to run on every branch so that every PR has it run, but I am not exactly sure how that parameter works. Is it what branch the PR is trying to merge into? If so then your change is probably good

The PR trigger makes the workflow run regardless of target branch. Using a wildcard for the branch trigger makes the workflow run regardless of the existence of a PR.

To just remove the duplicated runs but still run on every branch, the wildcard could be kept and the PR trigger removed entirely, but usually main branch + PRs are sufficient.

I agree, the changes to the CI here all make sense and look good to me.

@JoltedJon
As implemented prior, the CI would effectively run twice. Once when the PR was made, and again after it was merged.
While there is some value in this behavior on master, it is generally a waste of CI time on other branches.

I have gone ahead and approved the workflows to run. I think my only concern is I am not sure if arm64 will build and work properly or not at this time. I am not sure how many stub implementations for arm64 there are within the code base and build system at this time. I dont believe this architecture has really undergone any testing yet on account of all of the core devs working off of x86_64.

[Arctis-Fireblight]

It looks like everything built and tested properly for arm64, so I will go ahead and throw my approval on this.

[Shakai-Dev]

LGTM