Windows arm64 support - #318
Open
knightmare2600 wants to merge 6 commits into
Open
Conversation
relenv/build/windows.py already carried arm64 plumbing (OpenSSL VC-WIN64-ARM target, arch_to_plat/arch_to_archname mappings) that was never reachable because arches[WIN32] had arm64 commented out since 2022, pending "Python 11" support that has long since landed. Uncomment it so relenv build/create/fetch accept --arch arm64 on Windows. Add build_windows_arm64 and test_windows_arm64 jobs targeting the windows-11-arm hosted runner (native host==target, unlike the existing x86 job which cross-builds on windows-2022), plus an explicit VS ARM64 VC++ tools install step since install_vc_build.ps1 only ever requests the x86/x64 workload. Untested pending an actual CI run. Tracks saltstack#280.
MSFT_VSInstance (root/cimv2/vs) isn't registered on the windows-11-arm runner image even though VS 2022 Enterprise ships pre-installed there. The CI run against build_windows_arm64 confirmed this in practice: the script reported VS as "Missing" and spent 50+ minutes downloading and laying out a VS 2017 build-tools bundle instead of using the VS 2022 already on the box. Fall back to vswhere.exe -- present on every GitHub-hosted Windows image regardless of CIM provider support -- before concluding VS needs a from-scratch install.
setup-python has no arm64 Windows build for 3.10 ("The version '3.10'
with architecture 'arm64' was not found for Windows Enterprise") --
CPython's official arm64 Windows installers only started at 3.11. All
5 build_windows_arm64 jobs succeeded in the prior run (confirming the
native ARM64 CPython+OpenSSL build itself works); this only fixes the
verify job's own bootstrap interpreter, matching what
build_windows_arm64 already uses.
test_pip_install_cryptography and test_pip_install_idem failed on the windows arm64 build: pip fell back to compiling cryptography from source (no win_arm64 wheel exists yet -- nothing has ever shipped one for this target before), and openssl-sys couldn't find an OpenSSL to link against (OPENSSL_DIR unset, no vcpkg). relenv already builds OpenSSL from source for arm64 (update_openssl's VC-WIN64-ARM path); copy that install tree into the onedir as OpenSSL/ and archive it, then point OPENSSL_DIR at it in the two affected tests. No-op on every platform where OpenSSL comes from prebuilt binaries (prefix is never populated there) or where a wheel already exists.
Was added purely to dispatch CI runs manually while testing this branch without needing a PR. Not part of adding windows arm64 support; drop it to keep the change focused.
Author
|
The sister PR to this one for Salt is: saltstack/salt#70003 |
knightmare2600
added a commit
to knightmare2600/example_music_infra
that referenced
this pull request
Aug 10, 2026
Robert's added a custom ARM64 Windows Salt minion MSI, built by tracking three still-open, unmerged upstream PRs (confirmed live against the GitHub API, none merged as of 2026-08-10): - saltstack/salt#70003 -- native Windows arm64 minion MSI support - saltstack/relenv#318 -- Windows arm64 support (relenv, Salt's own relocatable Python builder, a real dependency of the minion build) - pymssql/pymssql#1013 -- native Windows arm64 wheel builds (a Salt dependency needed for the build to complete on arm64 at all) Renamed the existing MSI from the unsuffixed Salt-Minion-Setup.msi to Salt-Minion-Setup-x86_64.msi, and wired 82-salt-minion.yml to select Salt-Minion-Setup-{{ host_arch }}.msi -- reuses tasks/arch_facts.yml's own host_arch fact and naming convention (x86_64/arm64/x86) rather than inventing a new one, matching 50-binaries.yml's already-established pattern for exactly this problem. Added a loud, explicit failure for any architecture with no matching MSI at all, instead of a confusing win_copy "file not found" further down the task list. Also fixes a real harness gap check_playbook_dir_paths.py had: its own tail-matching regex excluded "{"/"}" outright, so it silently truncated and misreported the new host_arch-templated path as unresolvable -- a false positive, not a real bug. Fixed generically (glob-match any embedded {{ ... }} Jinja expression, require at least one real file to match) rather than special-cased to this one file, so it holds for any future playbook_dir path with a runtime-templated segment. Both the pass and fail paths of the fix tested directly before landing.
twangboy
approved these changes
Aug 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi,
I noticed that while the AMD64 Salt minion works fine on arm64 windows under emulation, it would be good to have native arm64 builds in the same manner as the Linux builds, e.g. Debian.
In order to make a native salt MSI, I had to also make some small amendments on this codebase. This PR covers those. It will need merged before the Salt minion arm64 windows build PR.