fix(windows): normalize Windows platform names in all toolchain files #193
Conversation
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
Windows builds have been failing on Windows Server 2025 with error:
"Unsupported platform windows server 2025_amd64"
The issue was that platform detection did not normalize Windows OS names.
GitHub Actions now uses "Windows Server 2025" which becomes
"windows server 2025_amd64" after lowercasing, but the checksum registry
expects "windows_amd64".
Changes:
- Fixed platform detection in 7 toolchain files to normalize Windows names:
* wasm_toolchain.bzl
* wasmtime_toolchain.bzl
* jco_toolchain.bzl
* wasi_sdk_toolchain.bzl
* cpp_component_toolchain.bzl
* symmetric_wit_bindgen_toolchain.bzl
* monitoring.bzl
- Note: tinygo_toolchain.bzl, wizer_toolchain.bzl, and wkg_toolchain.bzl
already had correct implementations
- Enabled Windows tests in PR CI (was only running on main branch)
* Reduced test matrix to latest Bazel versions only on PRs
* This ensures Windows issues are caught early
The fix uses pattern matching ("windows" in os_name) instead of exact
string comparison, so it will work with any Windows variant:
- Windows 10, Windows 11
- Windows Server 2019, 2022, 2025
- Future Windows versions
Windows releases of wasm-tools use .zip format, not .tar.gz format. This was causing 404 errors when trying to download wasm-tools on Windows. Changes: - Update wasm-tools.json: Change url_suffix from .tar.gz to .zip for all Windows entries - Update checksums to match actual Windows .zip files: - v1.235.0: ecf9f2064c2096df134c39c2c97af2c025e974cc32e3c76eb2609156c1690a74 (unchanged) - v1.239.0: 039b1eaa170563f762355a23c5ee709790199433e35e5364008521523e9e3398 (updated) - v1.240.0: 81f012832e80fe09d384d86bb961d4779f6372a35fa965cc64efe318001ab27e (updated) - Update _download_wasm_tools() to handle both .zip and .tar.gz archives Fixes: bytecodealliance/wasm-tools Windows download errors in BCR CI
avrabe
force-pushed
the
fix/windows-platform-detection
branch
from
3e778b6 to
1795b7a
Compare
Windows wkg checksum was wrong - using old wasm-tools checksum by mistake. Correct checksum: 930adea31da8d2a572860304c00903f7683966e722591819e99e26787e58416b Wrong checksum: 0019dfc4b32d63c1392aa264aed2253c1e0c2fb09216f8e2cc269bbfb8bb49b5 Fixed in all 3 locations: - checksums/tools/wkg.json - checksums/registry.bzl - toolchains/wkg_toolchain.bzl
Windows wac checksum was wrong for both v0.7.0 and v0.8.0. Also added missing v0.8.0 entry to wac.json (was only in registry.bzl). Correct checksum: 7ee34ea41cd567b2578929acce3c609e28818d03f0414914a3939f066737d872 Wrong checksum: d8c65e5471fc242d8c4993e2125912e10e9373f1e38249157491b3c851bd1336
v0.46.0 was using v0.43.0's Windows checksum (copypaste error). Correct v0.46.0 checksum: 95c6380ec7c1e385be8427a2da1206d90163fd66b6cbb573a516390988ccbad2 Wrong checksum (from v0.43.0): e133d9f18bc0d8a3d848df78960f9974a4333bee7ed3f99b4c9e900e9e279029
…proach - Document dependency management patterns in CLAUDE.md with clear decision matrix - Simplify toolchain strategies to download-only (remove build/source/hybrid options) - Migrate wasmsign2-cli to JSON registry for consistent security auditing - Clean up JSON registry files to keep only latest + previous stable versions * wasm-tools: 4 versions → 2 (1.240.0, 1.239.0) * file-ops-component: 3 versions → 2 (rc.3, rc.2) * nodejs: 3 versions → 2 (20.18.0, 18.20.8) * wasi-sdk: 3 versions → 2 (27, 26) * wasmtime: 3 versions → 2 (37.0.2, 35.0.0) - Update MODULE.bazel to use download strategy for wasm_toolchain This establishes clear patterns: - Multi-platform GitHub binaries → JSON Registry + secure_download - Bazel Central Registry deps → bazel_dep - Source builds → git_repository (when needed) - Universal WASM binaries → JSON Registry - NPM packages → hermetic npm Benefits: faster builds (prebuilt binaries), easier security audits (central checksums), simpler maintenance (one strategy per tool), clear documentation.
- Remove bazel/build/hybrid strategy support from wasm_toolchain.bzl - Simplify to download-only strategy (matching extensions.bzl cleanup) - Delete orphaned BUILD.wasm_tools_bazel and BUILD.wizer_bazel files - Add these files to .gitignore to prevent regeneration - Remove _setup_bazel_native_tools function (dead code) - Update all strategy references and error messages This completes the dependency management consolidation by removing unreachable code paths and simplifying the toolchain to use only prebuilt binary downloads from GitHub releases.
The stripPrefix was not removing .zip extension for Windows archives,
causing extraction errors on Windows CI:
Error: Prefix "wit-bindgen-0.46.0-x86_64-windows.zip" not found
Should be: "wit-bindgen-0.46.0-x86_64-windows"
This fix adds .replace(".zip", "") alongside .replace(".tar.gz", "")
to handle both Unix (.tar.gz) and Windows (.zip) archive formats correctly.
- Add windows_amd64 platform to wasi-sdk.json with verified SHA256 - Add windows_amd64 to fallback registry in registry.bzl - Checksum verified: 4a576c13125c91996d8cc3b70b7ea0612c2044598d2795c9be100d15f874adf6 - URL suffix corrected to x86_64-windows.tar.gz (matches actual release filename) This fixes Windows CI failure where WASI SDK was reported as unsupported: Error: Unsupported platform windows_amd64 for wasi-sdk version 27 Windows platform was in JSON but had PLACEHOLDER checksum, and was missing from the fallback registry used by get_tool_info().
Changed platform_mapping for windows_amd64 from "x86_64-mingw" to "x86_64-windows" to match the actual GitHub release filename format. This was causing 404 errors when downloading WASI SDK on Windows: Tried: wasi-sdk-27.0-x86_64-mingw.tar.gz (404 Not Found) Correct: wasi-sdk-27.0-x86_64-windows.tar.gz The mingw suffix was incorrect - WASI SDK uses "windows" in their release filenames.
Go 1.25.0 does not exist, causing 404 errors when downloading on all platforms: Error: GET returned 404 Not Found URL: https://go.dev/dl/go1.25.0.windows-amd64.tar.gz Updated to Go 1.25.3 which is the current latest stable release. This affects TinyGo's hermetic Go SDK download for all platforms.
Windows Go distributions use .zip format, not .tar.gz: Failing: https://go.dev/dl/go1.25.3.windows-amd64.tar.gz (404) Correct: https://go.dev/dl/go1.25.3.windows-amd64.zip (✓) Added conditional logic to select the correct archive format: - Windows: .zip - Linux/macOS: .tar.gz This fixes TinyGo toolchain setup on Windows.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Problem
Windows builds failing on Windows Server 2025:
Error: Unsupported platform windows server 2025_amd64Root Cause
Platform detection didn't normalize Windows OS names. GitHub Actions uses "Windows Server 2025" which becomes
windows server 2025_amd64after lowercasing, but registry expectswindows_amd64.Solution
Fixed platform detection in 7 toolchain files to use pattern matching:
Now uses
if "windows" in os_nameinstead of exact match, supporting all Windows variants.Additional Changes
Testing
CI validates Windows Server 2025, Ubuntu, macOS builds.