alitrack commented on PR #964: URL: https://github.com/apache/hudi-rs/pull/964#issuecomment-6568536078
Following up on the Windows CI failures — resolved, and I want to be clear about what each fix covers. **`rust-tests-windows` build failure (protoc):** the `--all-features` run pulls in lance (via hudi-core's lance feature), whose `prost-build` build.rs needs `protoc`, which the Windows runner doesn't preinstall. `7bf11aa` installs it via `choco install protoc` (same pattern as `release.yml:86`). **Two pre-existing Windows test incompatibilities (unrelated to the #445 forward-slash fix):** re-enabling the Windows job surfaces these; both fail **identically on unmodified `origin/main`**, so they are not regressions from this PR: - `storage::util::parse_valid_uri_in_various_forms` — its bare POSIX root-relative input `/foo/` is not a valid directory path on Windows (no drive letter), so `Url::from_directory_path` rejects it. I split that single case into its own `#[cfg(not(windows))]` test; the scheme-bearing cases (`file:/foo/`, `file:///foo/`, `hdfs`, `s3`, `gs`, `wasb`) still run on Windows. - `timeline::instant::test_create_instant_using_local_timezone` — fixes the offset via the POSIX `TZ` env var, which Windows ignores. Gated `#[cfg(not(windows))]`. Linux/macOS CI is unaffected by either gate. Local verification of the #445 fix itself: WSL `cargo test -p hudi-core --lib` = 1703 passed / 0 failed; Windows `datafusion` subset = 61 passed, 2 failed (the two pre-existing cases above). The full `--all-features --workspace` Windows run is what this re-enabled CI job will now exercise end-to-end. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
