82-salt-minion.yml: ARM64 Salt minion support via host_arch selection

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.

Author: knightmare2600

ansible/playbooks/salt/playbooks/10-master.yml

@@ -564,8 +564,9 @@
           - "  Ports       : 4505/tcp (publish), 4506/tcp (return)"
           - "════════════════════════════════════════════════════════════════"
           - "  Remaining manual steps:"
-          - "    1. Confirm bootstrap/web/windows/Salt-Minion-Setup.msi is the"
-          - "       matching {{ salt_version_major }}.x build (buildsheet-salt-minion.md)"
+          - "    1. Confirm bootstrap/web/windows/Salt-Minion-Setup-{x86_64,arm64}.msi"
+          - "       are the matching {{ salt_version_major }}.x build (buildsheet-salt-minion.md --"
+          - "       arm64 is a custom build, not an official release, see that doc's own caveat)"
           - "    2. Build/onboard a client endpoint (unattend XML or manual fallback)"
           - "    3. salt-key -L on this host to see the new minion's unaccepted key"
           - "    4. salt-key -a <minion-name> to accept it"

ansible/playbooks/windows_bootstrap/playbooks/82-salt-minion.yml

@@ -55,6 +55,22 @@
 # against installed products and skips the install if already present. Re-running this
 # playbook against an already-bootstrapped node does no work.
 #
+# ARM64 (added 2026-08-10, Robert): reuses tasks/arch_facts.yml's own host_arch fact/naming
+# convention (x86_64/arm64/x86, matching 50-binaries.yml's established pattern) rather than
+# inventing a new one -- two arch-suffixed MSIs now live side by side in bootstrap/web/windows/
+# (Salt-Minion-Setup-x86_64.msi, Salt-Minion-Setup-arm64.msi), selected by the same host_arch
+# fact every other arch-aware Windows playbook already uses. Unlike the x86_64 build (Salt
+# Project's own official release, SHA256-verified against Broadcom's response header -- see
+# docs/buildsheets/buildsheet-salt-minion.md), the arm64 build is NOT an official upstream
+# release -- native Windows arm64 support for the Salt minion doesn't exist upstream yet.
+# It's a custom build tracking three still-OPEN, unmerged PRs (salt#70003, relenv#318,
+# pymssql#1013 -- confirmed live against the GitHub API before this comment was written, all
+# three genuinely open, none merged) that together add the arm64 build capability. Treat this
+# build as experimental: it can't be refreshed the same "fetch + verify vendor checksum" way
+# as the x86_64 one, since there's no vendor release to fetch from -- rebuilding it means
+# re-applying those three PRs (or whatever they've evolved into) by hand. See that same
+# buildsheet section for the full caveat.
+#
 # FUTURE WORK -- custom grains (deferred, Robert has his own notes to bring back first, see
 # memory): when that lands, implement it as its OWN task(s), separate from the install task
 # above -- must not be nested inside or conditioned on "Salt wasn't already installed". Grains
@@ -71,16 +87,34 @@
 # Version history
 # =============================================================================
 # v1.0.0  2026-07-20  Initial release.
+# v1.1.0  2026-08-10  ARM64 support -- host_arch-based MSI selection (reuses
+#                     tasks/arch_facts.yml/50-binaries.yml's own convention),
+#                     Salt-Minion-Setup-x86_64.msi renamed from the previous
+#                     unsuffixed filename, Salt-Minion-Setup-arm64.msi added
+#                     (custom build, see header for the real caveat).
 # =============================================================================
 
 - name: Windows — Salt minion install
   hosts: "windows_nodes"
   gather_facts: false
   tasks:
 
+    - name: Detect CPU architecture
+      include_tasks: ../tasks/arch_facts.yml
+      tags: salt
+
+    - name: Fail loudly on an architecture with no Salt minion MSI at all
+      ansible.builtin.fail:
+        msg: >-
+          host_arch={{ host_arch }} has no Salt minion MSI in
+          bootstrap/web/windows/ -- only x86_64 (official) and arm64
+          (custom build, see this playbook's own header) exist.
+      when: host_arch not in ['x86_64', 'arm64']
+      tags: salt
+
     - name: Copy Salt minion MSI to the target host
       ansible.windows.win_copy:
-        src: "{{ playbook_dir }}/../../../../bootstrap/web/windows/Salt-Minion-Setup.msi"
+        src: "{{ playbook_dir }}/../../../../bootstrap/web/windows/Salt-Minion-Setup-{{ host_arch }}.msi"
         dest: "C:\\Windows\\Temp\\Salt-Minion-Setup.msi"
       tags: salt
 

at_have_ryggen_fri/check_playbook_dir_paths.py

@@ -49,6 +49,20 @@
 otherwise self-match as a phantom failure the same way a similar comment
 once did for a different check in this harness.
 
+Found 2026-08-10, a third variant: 82-salt-minion.yml's ARM64-support change
+introduced the first playbook_dir path with a genuine RUNTIME Jinja
+expression embedded in the trailing filename ("Salt-Minion-Setup-
+{{ host_arch }}.msi", host_arch resolved per-target at play time, not
+knowable statically). The original tail pattern excluded "{"/"}" outright,
+so it silently truncated the match at "Salt-Minion-Setup-" and reported a
+real, correctly-committed file as unresolvable -- a false positive, not a
+real bug. Fixed generically rather than special-cased to this one file:
+the tail pattern now matches a complete {{ ... }} block as a unit, and
+resolution substitutes any embedded Jinja expression with a glob wildcard,
+requiring at least one real file to match rather than one exact literal
+path -- holds for any future playbook_dir path with a runtime-templated
+segment, not just this one.
+
 Exit code: 0 if every playbook_dir-relative path resolves, 1 otherwise.
 """
 import re
@@ -58,9 +72,33 @@
 REPO_ROOT = Path(__file__).resolve().parents[1]
 ANSIBLE_DIR = REPO_ROOT / "ansible"
 
+JINJA_EXPR = re.compile(r"\{\{[^{}]*\}\}")
+
+
+def path_exists(base_dir, tail):
+    """A literal tail must exist exactly. A tail containing a runtime Jinja
+    expression (e.g. "Salt-Minion-Setup-{{ host_arch }}.msi") can't be
+    resolved to one real path statically -- substitute each {{ ... }} with
+    a glob wildcard instead and require at least one real file to match,
+    so a genuinely broken path (typo, wrong directory) still fails while a
+    correct runtime-templated one passes."""
+    if not JINJA_EXPR.search(tail):
+        resolved = (base_dir / tail).resolve()
+        return resolved.exists(), resolved
+    glob_pattern = JINJA_EXPR.sub("*", tail)
+    resolved = (base_dir / glob_pattern).resolve()
+    matches = list(base_dir.glob(glob_pattern))
+    return len(matches) > 0, resolved
+
 # {{ playbook_dir }}, then one or more /.. segments, then a trailing path
-# fragment up to whitespace, a quote, or a closing brace.
-PATTERN = re.compile(r"\{\{\s*playbook_dir\s*\}\}((?:/\.\.)+)/([^\s\"'{}]+)")
+# fragment up to whitespace or a quote. The fragment itself may contain a
+# runtime Jinja expression (e.g. "Salt-Minion-Setup-{{ host_arch }}.msi",
+# added 2026-08-10 for ARM64 Salt minion support) -- matched as a complete
+# {{ ... }} unit (internal spaces allowed) rather than excluded outright,
+# since the original tail pattern stopped dead at the first "{" and
+# silently truncated the match instead of flagging it as unresolvable.
+TAIL = r"(?:[^\s\"'{}]|\{\{[^{}]*\}\})+"
+PATTERN = re.compile(r"\{\{\s*playbook_dir\s*\}\}((?:/\.\.)+)/(" + TAIL + r")")
 
 # example_music_gate_repo_root: "{{ playbook_dir }}(/..)+ " -- bare, no
 # trailing path fragment, only ever combined with /benarbejde later inside
@@ -84,8 +122,9 @@ def main():
                 up_segments, tail = match.groups()
                 checked += 1
                 levels = up_segments.count("/..")
-                resolved = (path.parent / ("../" * levels) / tail).resolve()
-                if not resolved.exists():
+                base_dir = (path.parent / ("../" * levels)).resolve()
+                exists, resolved = path_exists(base_dir, tail)
+                if not exists:
                     failures.append((rel, match.group(0), levels, resolved))
 
             for match in GATE_ROOT_PATTERN.finditer(line):