-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Windows support #149
Comments
Some unordered thoughts:
There's nothing insurmountable, but Linux issues are higher yield for me at the moment. I will keep this tracking issue in mind though to at least try and stop the gap from getting worse. It's clearly important to make sure we get to Windows at some point, but I don't know how long it's going to take - any help on this front would be much appreciated! |
nanoserver would not work. It is so extremely stripped down that I have my doubts over whether even libstd would work. Windows Server 2016 has containers which use Docker. I don't know how fast they are but it is certainly something we could benchmark. There is plenty of documentation though so anyone who wants to work on this can fairly easily learn what they need to know. https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/ As long as we have VC++ installed and the environment configured using vcvars, then that should take care of almost all crates which are capable of working. |
Following up on this: given how much we rely on crater to detect potential breakage, we really do need this. Would it make sense to try to seek out some help from an appropriate Windows developer? If someone popped up willing to do this work, would the crater developers have time to work with them to get this in place? If so, it might make sense to put out a call for help here. |
Added a bunch of tasks that needs to be done at the top of the issue. Appveyor with Now that Craterbot is sort of running adding proper Windows support is going to be feasible, we "just" need to get an agent running on a Windows machine. Unfortunately I have almost no experience developing on Windows, but I'm happy to review PRs if someone wants to do the work. |
I've been doing a bit of work on this, so I thought I should post my progress here: I've published a proof-of-concept Docker container which installs the requirements for I've had some trouble building There's a single failing unit test on Windows (it expects the result to be a path using "/" as a separator) which I will submit a fix for at some point :). |
Whoa, thank you a lot for working on this! ❤️
Great! Can you send a PR to rust-lang/crates-build-env?
It would be awesome to get this into the docs on the repo. |
Another progress update: The modifications in #399 along with the new docker image are enough to get the unit tests passing and I'm planning to do a Windows |
@pietroalbini I thought I had seen an issue where you explained how to do a top 100 crater run, but I can't seem to find it now. Am I imagining things? Is this easy to do? Also, the latest commit to #399 run the unit tests on AppVeyor. Once rust-lang/crates-build-env#7 is merged, I'll enable the minicrater tests. Unfortunately, I believe that actually running containers requires an AppVeyor machine with nested virtualization. One exists, but I don't know if it's available in the free tier. |
Just pass
🎉
I'll try to figure if we can enable nested virtualization on our account, thanks for pointing this out. |
Support crater runs on Windows Resolves #149. This allows builds to run on [the newly added docker image](rust-lang/crates-build-env#5). In order to run successfully, you'll need to correctly [configure the Docker host](https://github.com/rust-lang/crater/blob/master/docs/agent-machine-setup-windows.md) ~~and `crater`'s `work` directory should have an ACL to enable full-access by the `"Authenticated Users"` group. This allows the container to write to the newly created `target` directories.~~ ~~The changes in the first commit don't belong in the finished product: Windows' permissions are [fundamentally different than the POSIX ones](https://en.wikipedia.org/wiki/Access_control_list) so I need to think more about how to change the current API to be more cross-platform. However, `.exe`s are executable by default on Windows and user remapping isn't done within the container anyways, so my changes were enough to this PR up and running.~~ ~~I couldn't get OpenSSL to link properly when building crater on Windows, despite setting `OPENSSL_DIR`, so I've temporarily reverted "switch from ring to openssl" to let me run tests. This should be un-reverted before this is merged.~~ ~~The last commit points to a self-published version of the docker image, not a `rust-ops` published one. An official version can be published once I get [CI up and running](rust-lang/crates-build-env#5 (comment)) for the Windows image.~~ The concerns listed above have all been resolved. The ACL change seems to have been obsoleted by later versions of Docker on Windows.
Now that #399 is merged, crater runs are possible on Windows. Work to build as many crates as possible by adding dependencies to The next step is to make |
Opened an issue with rough intructions to make Ping me on that issue or Discord if y'all need mentoring. |
There's a large number of crates out there which are Windows specific, so it is essential that crater be able to test those crates.
CLI usage on Windows
cargo check
on Appveyorcargo build
on Appveyorsrc/native/windows.rs
native
modulecargo test
on AppveyorCraterbot support for Windows
Reference material
The text was updated successfully, but these errors were encountered: