让 Windows CI 真正运行 Rust 后端单测#370
Closed
H-Chris233 wants to merge 15 commits into
Closed
Conversation
|
Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits. |
H-Chris233
force-pushed
the
fix/windows-ci-run-rust-tests
branch
from
9a5e26d to
3209980
Compare
PR Reviewer Guide 🔍(Review updated until commit 6e7e546)Here are some key observations to aid the review process:
|
|
Persistent review updated to latest commit 3209980 |
H-Chris233
force-pushed
the
fix/windows-ci-run-rust-tests
branch
2 times, most recently
from
51110f1 to
2ff8a9d
Compare
|
Persistent review updated to latest commit 51110f1 |
H-Chris233
force-pushed
the
fix/windows-ci-run-rust-tests
branch
2 times, most recently
from
323eed9 to
ce8c084
Compare
|
Persistent review updated to latest commit 323eed9 |
H-Chris233
force-pushed
the
fix/windows-ci-run-rust-tests
branch
from
ce8c084 to
64117dc
Compare
|
Persistent review updated to latest commit ce8c084 |
H-Chris233
force-pushed
the
fix/windows-ci-run-rust-tests
branch
from
64117dc to
9a7a0b5
Compare
|
Persistent review updated to latest commit 64117dc |
|
Persistent review updated to latest commit 9a7a0b5 |
H-Chris233
force-pushed
the
fix/windows-ci-run-rust-tests
branch
2 times, most recently
from
b5a7be3 to
e0d29a4
Compare
|
Persistent review updated to latest commit b5a7be3 |
Windows CI needs to execute the Rust backend unit tests, not stop at --no-run, but the Foundry WinML SDK linked into the default Windows build exits the GitHub Windows Server test process before the Rust harness starts with STATUS_ENTRYPOINT_NOT_FOUND. The product default remains unchanged: the default feature set still includes Foundry Local runtime support and cargo check continues to cover that linked shape.\n\nFor the Windows unit-test gate, build the lib tests without the native Foundry runtime feature so the harness can start and exercise coordinator, hotkey, insertion, recorder, persistence, and command tests on Windows. The Foundry runtime implementation now has an explicit unavailable stub for Windows builds that disable the feature, matching the existing non-Windows fallback shape.\n\nConstraint: GitHub Windows Server runners cannot currently execute the default Foundry/WinML-linked test harness before Rust tests start.\n\nRejected: Keep --no-run permanently | it leaves Windows-specific unit regressions unexecuted.\n\nRejected: Install Windows App Runtime and Foundry DLLs in CI | the harness still failed before running tests.\n\nRejected: Put Foundry DLLs on PATH | it risks loader pollution and did not resolve the startup failure.\n\nConfidence: medium\n\nScope-risk: moderate\n\nDirective: Keep default product builds on foundry-local-runtime unless the local ASR product decision changes; the no-default Windows CI command is specifically a unit-test harness escape hatch.\n\nTested: git diff --check; cargo test --manifest-path openless-all/app/src-tauri/Cargo.toml --lib; cargo test --manifest-path openless-all/app/src-tauri/Cargo.toml --lib --no-default-features --features custom-protocol.\n\nNot-tested: Windows GitHub runner execution after the no-Foundry test-harness split before PR CI.
H-Chris233
force-pushed
the
fix/windows-ci-run-rust-tests
branch
from
e0d29a4 to
ead35f4
Compare
|
Persistent review updated to latest commit e0d29a4 |
Windows CI first checks the default Tauri backend build, then runs unit tests with Foundry disabled so the test harness can execute on the hosted runner. Keeping those builds in one target directory can leave unrelated native artifacts in the loader search area, so the unit-test lane now uses a dedicated target directory while the product default feature set remains covered by cargo check. Constraint: Windows hosted runner fails before Rust tests start with STATUS_ENTRYPOINT_NOT_FOUND after the default-feature check step.\nRejected: Remove the default-feature cargo check | that would stop covering the product Foundry-enabled build shape.\nConfidence: medium\nScope-risk: narrow\nDirective: Keep the Windows unit-test target directory separate from the default-feature check unless the native Foundry runner issue is proven gone.\nTested: git diff --check\nTested: cargo test --manifest-path src-tauri/Cargo.toml --lib --no-default-features --features custom-protocol
The Windows runner still fails before executing the lib test binary when newest stable links the harness to WaitOnAddress through api-ms-win-core-synch-l1-2-0.dll. The lockfile already requires Rust 1.88, so the Windows unit-test lane now uses that minimum compatible toolchain while macOS and Linux continue tracking stable. Constraint: CI must run the Windows tests instead of returning to cargo test --no-run.\nConstraint: Current dependency graph requires Rust 1.88 or newer.\nRejected: Pin all platforms | the failure is Windows-runner-specific and broadens CI drift unnecessarily.\nConfidence: medium\nScope-risk: narrow\nDirective: Do not raise the Windows CI toolchain without checking that the test executable starts on the hosted Windows runner.\nTested: git diff --check\nTested: cargo test --manifest-path src-tauri/Cargo.toml --lib --no-default-features --features custom-protocol
Windows CI now runs Rust unit tests for real, so the test executable must not import APIs that are unavailable in the runner loader environment. The only local use of the broad Win32_System_Threading binding was GetCurrentThreadId for the hotkey hook shutdown path, while that feature also pulled WaitOnAddress through the generated windows crate bindings. Constraint: Windows CI failed before tests started with STATUS_ENTRYPOINT_NOT_FOUND on api-ms-win-core-synch-l1-2-0.dll / WaitOnAddress. Rejected: Return to cargo test --no-run | issue Open-Less#295 requires actual backend test execution on Windows. Rejected: Keep Win32_System_Threading and rely on a newer runner | the failure persisted after pinning Rust to the lockfile MSRV. Confidence: medium Scope-risk: narrow Directive: Keep the Windows test binary free of broad generated bindings that import unavailable loader symbols unless CI proves they execute on GitHub runners. Tested: git diff --check Tested: cargo test --manifest-path src-tauri/Cargo.toml --lib --no-default-features --features custom-protocol Tested: cargo check --manifest-path src-tauri/Cargo.toml
The previous fix removed a broad project-level Threading binding, but CI evidence showed the Rust test executable still imports WaitOnAddress before tests start. Keep the no-Foundry test build, compile the test binary first, place the official Windows Kits x64 API-set redist DLL beside it, and then run cargo test so the Windows backend tests still execute for real. Constraint: GitHub Windows Server 2022 runner exits the Rust test process with STATUS_ENTRYPOINT_NOT_FOUND for api-ms-win-core-synch-l1-2-0.dll / WaitOnAddress. Rejected: cargo test --no-run as the final gate | issue Open-Less#295 requires actual test execution. Rejected: Disable Foundry Local product defaults | only the CI test harness should remove native Foundry startup. Confidence: medium Scope-risk: narrow Directive: The no-run phase is only preparation for DLL placement; do not remove the following cargo test execution. Tested: git diff --check Not-tested: Windows runner API-set redist path until PR CI reruns
Copying the Windows Kits API-set redist DLL did not resolve the runner loader failure because that stub still lacked the imported WaitOnAddress export. The CI harness now builds a tiny x64 DLL named api-ms-win-core-synch-l1-2-0.dll beside the Rust test executable; it forwards WaitOnAddress and WakeByAddress* to KernelBase/kernel32, then cargo test executes normally. Constraint: GitHub Windows Server 2022 still exited the test process with STATUS_ENTRYPOINT_NOT_FOUND after the Windows Kits redist DLL was copied beside the exe. Rejected: Keep the redist-copy workaround | dumpbin evidence showed the loader still could not resolve WaitOnAddress. Rejected: Return to --no-run-only | issue Open-Less#295 requires actual Windows test execution. Confidence: medium Scope-risk: narrow Directive: The shim is CI-only and must stay in the test exe directory; do not ship it in product bundles. Tested: git diff --check Not-tested: Shim compilation and loader behavior until PR CI reruns
Rust 1.78+ Windows test runners can trip over WaitOnAddress/API-set resolution in hosted runner environments. Replace the shim and Rust-version pin experiments with the documented runner-level mitigation: keep Windows CI on Server 2022 and run the backend tests for real. Constraint: Issue Open-Less#295 requires actual Windows Rust unit test execution, not cargo test --no-run. Constraint: Product default Foundry Local runtime remains enabled; only the CI test build disables the native Foundry feature. Rejected: CI-local API-set shim | too invasive before exhausting the known runner-image workaround. Rejected: Pin Rust 1.88 | did not address the loader failure and drifted from normal stable CI. Confidence: medium Scope-risk: narrow Tested: git diff --check Tested: cargo test --manifest-path src-tauri/Cargo.toml --lib --no-default-features --features custom-protocol Tested: cargo check --manifest-path src-tauri/Cargo.toml
|
Persistent review updated to latest commit 948e981 |
Server 2022 did not remove the hosted-runner loader failure: cargo built the lib test binary, then the process exited before any test with STATUS_ENTRYPOINT_NOT_FOUND while importing WaitOnAddress from api-ms-win-core-synch-l1-2-0.dll. Keep the Server 2022 pin, but make the Windows test step build the test exe first and place a CI-local API-set forwarding shim in that exe directory before running cargo test for real. The shim is scoped to the unit-test target directory and forwards only WaitOnAddress/WakeByAddress* to KernelBase/kernel32. Constraint: Issue Open-Less#295 requires actual Windows Rust unit test execution rather than cargo test --no-run. Constraint: Product default Foundry Local runtime remains enabled; only the CI test build disables the native Foundry feature. Rejected: Runner-only mitigation | windows-2022 still failed with STATUS_ENTRYPOINT_NOT_FOUND on the test harness. Rejected: Ship or source-control a DLL | the workaround is CI-local and generated into the temporary test target directory only. Confidence: medium Scope-risk: narrow Directive: Do not remove the shim unless Windows CI proves cargo test executes the backend test binary without the api-ms WaitOnAddress loader failure. Tested: git diff --check Tested: YAML parsed with python yaml.safe_load
The CI-local API-set shim built successfully, but the Windows loader still failed before running tests, which indicates the API-set contract import is resolved before app-local DLL search can help. After cargo test --no-run, patch the generated lib test executable import name from api-ms-win-core-synch-l1-2-0.dll to KernelBase.dll, where Server 2022 exports WaitOnAddress, then invoke cargo test normally so the harness still executes the Rust unit tests. Constraint: Issue Open-Less#295 requires actual Windows Rust unit test execution rather than compile-only coverage. Rejected: App-local API-set shim | the loader still failed after the shim DLL was placed beside the test executable. Rejected: Returning to cargo test --no-run | that would not satisfy the ticket. Confidence: medium Scope-risk: narrow Directive: Keep this patch scoped to CI test binaries; do not apply binary import rewriting to shipped artifacts. Tested: git diff --check Tested: YAML parsed with python yaml.safe_load
The Windows runner can build the Rust lib test binary, but invoking cargo test a second time after the import-string patch relinks the executable and loses the patch before any unit test starts. The CI step now builds with --no-run, patches the generated harness, verifies the API-set import is gone, and executes that harness directly so the backend tests still run for real.\n\nConstraint: GitHub Windows runners fail the Rust-generated WaitOnAddress API-set import before test code starts.\nRejected: Re-run cargo test after patching | Cargo can rebuild/relink and replace the patched executable.\nConfidence: medium\nScope-risk: narrow\nDirective: Keep this workaround confined to Windows CI unit tests; product defaults must keep Foundry Local runtime enabled.\nTested: git diff --check; python yaml.safe_load(.github/workflows/ci.yml); cargo test --manifest-path src-tauri/Cargo.toml --lib --no-default-features --features custom-protocol\nNot-tested: Windows GitHub runner after direct harness execution
|
Persistent review updated to latest commit eb157ba |
|
Persistent review updated to latest commit ca1a80e |
The Server 2022 runner still fails Rust test startup with the WaitOnAddress API-set import, and binary patching only turns that loader abort into another pre-harness failure. OpenLess declares Rust 1.77 as its MSRV, so the Windows CI unit-test lane now installs 1.77.0 and executes the no-Foundry test build directly instead of editing generated executables.\n\nConstraint: Issue Open-Less#295 requires Windows CI to run the Rust unit tests, not just compile them.\nRejected: Continue PE import patching | the patched harness still exits before tests print output on GitHub Windows.\nConfidence: medium\nScope-risk: narrow\nDirective: Keep product/default toolchain behavior covered by cargo check; this pin is only for the Windows unit-test execution lane.\nTested: git diff --check; python yaml.safe_load(.github/workflows/ci.yml); cargo test --manifest-path src-tauri/Cargo.toml --lib --no-default-features --features custom-protocol\nNot-tested: Windows GitHub runner with Rust 1.77.0 until CI completes
The MSRV pin cannot build the current dependency graph because newer transitive crates use edition2024 manifests. Keep the normal stable toolchain, but install Rust's x86_64-win7-windows-msvc target for the Windows unit-test lane so std uses the compatibility path instead of a direct WaitOnAddress API-set import. The default Windows target remains checked separately by cargo check.\n\nConstraint: Windows CI must execute backend tests while preserving the product's default Windows target coverage.\nRejected: Pin Rust 1.77.0 | current transitive dependency manifests require newer Cargo support.\nConfidence: medium\nScope-risk: narrow\nDirective: Do not replace the default Windows cargo check with the win7 target; it is only a test-execution workaround.\nTested: git diff --check; python yaml.safe_load(.github/workflows/ci.yml); cargo test --manifest-path src-tauri/Cargo.toml --lib --no-default-features --features custom-protocol\nNot-tested: Windows GitHub runner with x86_64-win7-windows-msvc until CI completes
The Windows runner PATH reports Git's link.exe before the Visual Studio linker, which makes the previous loader-focused attempts too fragile. The CI now resolves VsDevCmd.bat explicitly and runs Windows cargo check plus the real unit-test command inside that MSVC environment, while keeping macOS/Linux unchanged.\n\nConstraint: Windows CI must execute the Rust backend unit tests without changing product code paths.\nRejected: x86_64-win7-windows-msvc target | stable toolchains do not ship prebuilt std artifacts for that target.\nConfidence: medium\nScope-risk: narrow\nDirective: Keep Windows cargo commands under VsDevCmd unless the runner PATH is proven to expose the real MSVC linker first.\nTested: git diff --check; python yaml.safe_load(.github/workflows/ci.yml)\nNot-tested: Windows GitHub runner after VsDevCmd wrapping until CI completes
|
Persistent review updated to latest commit 960cab1 |
|
Persistent review updated to latest commit 6e7e546 |
Server 2022, MSRV pinning, direct harness execution, and explicit VsDevCmd still do not make the stable Windows test harness start on the runner. The remaining narrow CI-only path is to keep stable cargo check for the product Windows target, but execute unit tests with nightly build-std on x86_64-win7-windows-msvc so std avoids the direct WaitOnAddress API-set import.\n\nConstraint: Issue Open-Less#295 requires actual Windows test execution; stable default-target harness exits before tests begin on GitHub runners.\nRejected: Use prebuilt win7 target std | stable does not ship artifacts for x86_64-win7-windows-msvc.\nConfidence: medium\nScope-risk: moderate\nDirective: This is a CI-only test harness workaround; do not infer product support for Windows 7 from it.\nTested: git diff --check; python yaml.safe_load(.github/workflows/ci.yml)\nNot-tested: Nightly build-std Windows CI until the workflow completes
The nightly build-std win7 target path cannot compile Tauri's ctor usage, while the previous KernelBase import rewrite still exited before harness output. Keep the no-run/direct-harness approach, but point the WaitOnAddress import at Kernel32.dll and print the native exit code when the patched harness fails.\n\nConstraint: Windows CI still needs real unit-test execution and GitHub runners reject the Rust API-set import before tests start.\nRejected: Nightly build-std win7 target | tauri-utils ctor is unsupported on that target.\nConfidence: low\nScope-risk: narrow\nDirective: If Kernel32 also fails, stop treating PE patching as proven and prefer a test-architecture split or upstream runner/toolchain fix.\nTested: git diff --check; python yaml.safe_load(.github/workflows/ci.yml)\nNot-tested: Kernel32 import patch on Windows CI until workflow completes
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.
User description
摘要
cargo test --lib --no-run恢复为真正执行cargo test --lib背景
PR #361 合并后，Windows job 只能编译测试二进制，原因是干净 runner 缺少可选 native runtime 时测试进程在 harness 启动前报
STATUS_ENTRYPOINT_NOT_FOUND。这次按“方案一”补齐运行时，让 Windows CI 执行同一套 Rust 后端单测，而不是只做 link 覆盖。验证
cargo test --manifest-path openless-all/app/src-tauri/Cargo.toml --libcargo check --manifest-path openless-all/app/src-tauri/Cargo.tomlnpm run build未验证
PR Type
Bug fix, Enhancement
Description
Add
foundry-local-runtimefeature to gate native runtime dependencyRun Windows unit tests with no-default-features and
win7target to avoid runtime conflictsProvide stub runtime implementation for non-feature builds with proper cancellation support
Pin CI runner to
windows-2022and use separate target dir for test buildsDiagram Walkthrough
File Walkthrough
foundry_runtime.rs
Gate native runtime behind feature flag for test isolationopenless-all/app/src-tauri/src/asr/local/foundry_runtime.rs
foundry-local-runtimefeature
cancel_preparesupport for non-feature buildsci.yml
Execute Windows unit tests without native runtime linkage.github/workflows/ci.yml
windows-2022x86_64-win7-windows-msvcRust target for test compatibility--target win7,--no-default-features, and customfeature set
Cargo.toml
Make native runtime dependency optional via feature flagopenless-all/app/src-tauri/Cargo.toml
foundry-local-sdkdependency optionalfoundry-local-runtimefeature that enables the SDK