ci: run rust-tests on windows

[crrow]

Description

Use cargo-binstall to install tarpaulin.

#90

How are the changes test-covered

• N/A
• Automated tests (unit and/or integration tests)
• Manual tests
  • Details are described below

[xushiyan]

@crrow thanks for the fix! interestingly the CI job wasn't even triggered. any idea what's going on?

[xushiyan]

@crrow i suspect your previous approach using binstall could work but the github action was not whitelisted by asf so the whole workflow is not triggered. if you can verify that binstall approach in your own fork and get CI to pass, then i can reach out to have that white listed.

[crrow]

@crrow i suspect your previous approach using binstall could work but the github action was not whitelisted by asf so the whole workflow is not triggered. if you can verify that binstall approach in your own fork and get CI to pass, then i can reach out to have that white listed.

ok, i'll check it out later.

[crrow]

@crrow i suspect your previous approach using binstall could work but the github action was not whitelisted by asf so the whole workflow is not triggered. if you can verify that binstall approach in your own fork and get CI to pass, then i can reach out to have that white listed.

ok, i'll check it out later.

Hello @xushiyan , I setup the workflow, have a check when you are free.

https://github.com/crrow/hudi-rs/actions/runs/10122608881/job/27994952767

[xushiyan]

@crrow using cargo-bins/cargo-binstall works! The job fails due to some test failure - can you look into and fix any code if needed? meanwhile i'll get binstall whitelist so it can be triggered here.

[crrow]

@xushiyan I'd love to, but I'd prefer to address the Windows code in a separate pull request.

[crrow]

What's your thought on separator and test case? Some test failed because of rust's automatic normalize, and URL parse failed since some test cases are Linux path, and it cannot be parsed on Windows.

By the way, I think some test cases can be rewritten with https://crates.io/crates/test-case

[xushiyan]

@crrow absolutely! we should separate test code fix from CI setup change. Feel free to create another PR for the test fix wrt url parsing. You may also make the code change here so we know the test fix can pass with the CI, then separate it out. It's up to you.

I've thought about using some test helper lib but not sure if https://github.com/frondeus/test-case is the best candidate. there are many crates maintained by community like https://github.com/la10736/rstest seems more popular with more recent releases. I'll create an issue about this for future refactoring work.

[crrow]

@xushiyan Do we have to handle this case? , its tricky for windows

[xushiyan]

@xushiyan Do we have to handle this case? , its tricky for windows

@crrow that path is a unix path which should not be applicable to windows os. Can we split that case to test case which does not run on windows, and also add a windows specific test case with an example windows path ?

[crrow]

Sure, I'd love to

[crrow]

Oh...I found that its still tricky, like "C:\foo", url::parse will success, it thoughts 'c' is the schema, rather than a filepath; for "\foo", url::parse and url::from_filepath will all fail; We can handle both cases by adding additional check like if current os is windows and the given str has ":\".

Can we be stricter about what qualifies as a 'valid URL'? Like a valid URL must have a schema.

[xushiyan]

@crrow would you do a bit of research on how windows paths are usually handled in consideration of scheme? we want to be flexible in supporting paths - it can start with C:\, file:///, /, s3:// as these are valid paths anyway.