ci: add Windows ARM64 binary to release workflow

[feloy]

Add aarch64-pc-windows-msvc to the build matrix, cross-compiled from the existing x64 Windows runner via the MSVC ARM64 toolchain (no cross tool required). Generalize the .exe suffix condition to cover all windows targets.

Closes #82

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[coderabbitai]

📝 Walkthrough

Walkthrough

GitHub Actions release workflow fixes the Windows ARM build target declaration and broadens artifact naming logic. The aarch64-pc-windows-msvc matrix entry is now correctly configured with proper target and runner values. The artifact upload step now applies the .exe suffix to all Windows targets via contains(matrix.target, 'windows') instead of hardcoding a single target.

Changes

Windows ARM Build Support

Layer / File(s)	Summary
Windows ARM matrix fix and artifact naming .github/workflows/release.yml	The aarch64-pc-windows-msvc build matrix entry is corrected with aligned target and runner configuration. The artifact upload step is generalized to check contains(matrix.target, 'windows') for the .exe suffix, supporting both x86_64-pc-windows-msvc and aarch64-pc-windows-msvc targets.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately describes the main change: adding Windows ARM64 support to the release workflow.
Description check	✅ Passed	The description clearly explains the changes made and references the closed issue, directly relating to the changeset.
Linked Issues check	✅ Passed	The PR successfully adds Windows ARM64 binary generation by including aarch64-pc-windows-msvc in the build matrix [#82], meeting the linked issue requirement.
Out of Scope Changes check	✅ Passed	All changes are scoped to the release workflow and directly support the objective of enabling Windows ARM64 binary generation without introducing unrelated modifications.
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.}

---

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]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)

.github/workflows/release.yml (2)

24-27: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Restrict default GITHUB_TOKEN permissions for least privilege.

Line 24 onward defines jobs without a workflow-level permissions baseline, so the build job inherits repository defaults. That is broader than needed for compile/upload-artifact steps and increases blast radius if compromised.

Suggested hardening

 name: Release
 
 on:
   push:
     tags:
       - "v*"
+
+permissions:
+  contents: read
 
 jobs:
   build:

🤖 Prompt for 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.

In @.github/workflows/release.yml around lines 24 - 27, Add an explicit
permissions baseline to the workflow to restrict the default GITHUB_TOKEN scopes
(rather than relying on repo defaults): add a top-level permissions block and
grant only the minimal scopes required for the build/upload-artifact steps
(e.g., contents: read and actions/artifacts-related scopes as needed), and if
some jobs need extra rights override permissions on that specific job (reference
jobs.build and any other job names to set job-level permissions). Ensure the new
permissions block is at workflow level so every job inherits least-privilege by
default, and only elevate per-job where necessary.

Source: Linters/SAST tools

---

47-47: ⚠️ Potential issue | 🟠 Major

Update dtolnay/rust-toolchain version comments to exact release versions

In .github/workflows/release.yml lines 47 and 178, the pins use dtolnay/rust-toolchain@e97e2d8cc328f1b50210efc529dca0028893a2d9 but the comment is only # v1 (major-only). Replace # v1 with the exact release version for that pinned commit.

uses: dtolnay/rust-toolchain@e97e2d8cc328f1b50210efc529dca0028893a2d9 # v1

🤖 Prompt for 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.

In @.github/workflows/release.yml at line 47, Replace the generic “# v1” comment
on the pinned action commit
dtolnay/rust-toolchain@e97e2d8cc328f1b50210efc529dca0028893a2d9 with the exact
release tag that corresponds to that commit (update both occurrences of the same
pin around the uses:
dtolnay/rust-toolchain@e97e2d8cc328f1b50210efc529dca0028893a2d9), i.e., locate
the two places where that full commit SHA is used and change the trailing
comment from “# v1” to the precise release version string for that commit.

Source: Coding guidelines

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

Outside diff comments:
In @.github/workflows/release.yml:
- Around line 24-27: Add an explicit permissions baseline to the workflow to
restrict the default GITHUB_TOKEN scopes (rather than relying on repo defaults):
add a top-level permissions block and grant only the minimal scopes required for
the build/upload-artifact steps (e.g., contents: read and
actions/artifacts-related scopes as needed), and if some jobs need extra rights
override permissions on that specific job (reference jobs.build and any other
job names to set job-level permissions). Ensure the new permissions block is at
workflow level so every job inherits least-privilege by default, and only
elevate per-job where necessary.
- Line 47: Replace the generic “# v1” comment on the pinned action commit
dtolnay/rust-toolchain@e97e2d8cc328f1b50210efc529dca0028893a2d9 with the exact
release tag that corresponds to that commit (update both occurrences of the same
pin around the uses:
dtolnay/rust-toolchain@e97e2d8cc328f1b50210efc529dca0028893a2d9), i.e., locate
the two places where that full commit SHA is used and change the trailing
comment from “# v1” to the precise release version string for that commit.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 8e66b0ba-4e77-4235-9469-31db485f4cd0

📥 Commits

Reviewing files that changed from the base of the PR and between 3aef14c and e942b2b.

📒 Files selected for processing (1)

• .github/workflows/release.yml