fix(smoke): derive arch from CI matrix, not emulated uname (arm64 12a)#907
Merged
Conversation
The persistent windows-11-arm smoke Phase 12a failure was a 404, not a network error: it requested codebase-memory-mcp-windows-amd64.zip on the arm64 leg. Cause: DL_ARCH came from `uname -m`, which on windows-11-arm is an emulated x86_64 MSYS2 uname reporting "x86_64" -> wrong (amd64) archive -> 404 (server has arm64). Phase 14 worked because the binary's own detect_arch() is native. Prefer SMOKE_ARCH (passed from the smoke workflow's matrix.arch) over uname; fall back to uname for local runs. This is the real cause the earlier curl/proxy/ipv4 attempts masked -- the 404 was swallowed by 2>/dev/null until #905 surfaced it. Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
This was referenced Jul 6, 2026
pull Bot
pushed a commit
to MrDolphin/codebase-memory-mcp
that referenced
this pull request
Jul 6, 2026
…URE (arm64) install.ps1 reported "arch: amd64" on windows-11-arm and 404'd on the amd64 zip: $env:PROCESSOR_ARCHITECTURE reports the emulated "AMD64" for an x64 process under ARM64 emulation, and PROCESSOR_ARCHITEW6432 is unset for 64-bit emulated procs. RuntimeInformation.OSArchitecture reports the real OS arch (Arm64) regardless of process emulation. Same emulated-arch class as the smoke uname fix (DeusData#907); this one is a genuine product improvement -- real ARM users invoking install.ps1 from an x64 context now get the arm64 binary. Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
pull Bot
pushed a commit
to MrDolphin/codebase-memory-mcp
that referenced
this pull request
Jul 6, 2026
…e 13) install.ps1 kept detecting arch=amd64 on windows-11-arm because it runs under x64 emulation, where neither $env:PROCESSOR_ARCHITECTURE nor .NET OSArchitecture (on Windows PowerShell 5.1) reports the real Arm64. Add a CBM_ARCH env override to install.ps1 (wins over auto-detect; also a genuine escape hatch for emulated invocations) and have smoke Phase 13 pass the authoritative DL_ARCH. Deterministic -- no reliance on in-process detection under emulation. Same emulated-arch class as DeusData#907 (uname) and DeusData#908. Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
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
1 participant
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.
The persistent windows-11-arm smoke Phase 12a failure was a 404, not a network
error: it requested codebase-memory-mcp-windows-amd64.zip on the arm64 leg. Cause:
DL_ARCH came from
uname -m, which on windows-11-arm is an emulated x86_64 MSYS2uname reporting "x86_64" -> wrong (amd64) archive -> 404 (server has arm64). Phase
14 worked because the binary's own detect_arch() is native. Prefer SMOKE_ARCH
(passed from the smoke workflow's matrix.arch) over uname; fall back to uname for
local runs. This is the real cause the earlier curl/proxy/ipv4 attempts masked --
the 404 was swallowed by 2>/dev/null until #905 surfaced it.