-
Notifications
You must be signed in to change notification settings - Fork 5
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
feat: windows #45
feat: windows #45
Conversation
examples\module>bazel test //:integration_test --test_output=all
D:\udu\b\eheyrjsw\execroot_main\bazel-out\x64_windows-fastbuild\bin\integration_test.exe.runfiles_main is empty Any clues? Thank you! |
(.venv) d:\workdir\rules_multitool\examples\module>bazel run @multitool//tools/target-determinator:cwd
I think we need to pass ext into cwd rule somehow, can this have access to toolchain? |
I’m guessing, but I suspect you need to set some kind of extension for the output filename of the cwd target, right now we declare the output file to be the same name as the target, but you may need to set it to |
cwd and tests are passing now, thanks for the inputs that helped. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have to do all the stuff with file extensions on Windows? It seems like, for instance, the batch script for cwd didn't need the extension in order to be runnable.
Yes, windows requires files to have 'exe' 'bat' or 'cmd' extensions to be executed. There is no 'execute' file bit. The cwd batch script does end up with an extension (cwd.bat) |
something was fixed in bazel 7.1.0 (broken in 7.0.2) related to symlinks on windows. It's corrected some of the issues I'm seeing. |
I could bump .bazelversion to 7.1.0, or 7.2.0 which I'm using quite happily in my repo; any preferences? |
I'm not sure if there's a way to guard windows support behind a Bazel version, but that'd probably be the ideal setup vs. assuming an incrementally higher minimum version. Otherwise bumping the repo to 7.1.0 is probably fine. |
I've implemented a version check that kicks in on all platforms if any windows artifacts are seen in the lockfile. And I've also bumped repo version to 7.1.0 so that check does not fire. The version check is not bulletproof; when bazel runs off a commit hash or latest it doesn't report a version so I can't check. |
Could you try a CI run? |
.github/workflows/ci.yml
Outdated
# our CI only supports linux and macos | ||
exclude_windows: true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually can you take this away so that the Windows CI runs now that you've added support?
Looks like just a buildifier failure. |
Is there some way I can see the test log from buildifier? It's passing locally |
never mind, it's failing locally on linux, passing on windows ;-). I'll fix the linux failures |
#46 should make the errors visible in CI if you rebase/merge main |
Co-authored-by: Mark Elliot <123787712+mark-thm@users.noreply.github.com>
I think that buildifier_prebuilt has a windows bug that causes it to silently not run. I'll chase that up when I integrate it into our repo Interestingly, they do have a way to handle invoking tools through a wrapper when runfiles are disabled. Some bash code that parses the manifest. That might be worth looking at in future. |
Buildifier is fixed, can you try another CI? |
Interestingly it looks like buildifier.test is failing when |
Looks like that's a version-sensitive bug, we can bump buildifier_prebuilt to 6.4.0 and call it a day. |
awesome! thanks for your support 🥳 |
Thanks for taking the time to improve this ruleset! |
I had a bit of trouble with 7.1.x, specifically in cases where repo rules had errors bazel would hang. I'm seeing it fixed in 7.2.0, so if you get trouble with the current version that's the easy fix. |
Neat! I'm adding multitool fetch ruff in https://github.com/aspect-build/rules_lint/actions/runs/9811753252/job/27094364261?pr=309 where I included Windows. However that repo has a test on Bazel 6. Something seems wrong because I get the new error message even for a repo I guess rules_lint can't offer anyone windows binaries until all users are forced to upgrade Bazel? That's probably not desirable. |
It’s possible there’s a version of Bazel 6 with the same patch in 7.1+, happy to expand the range if you want to test that? |
Also will note that you need Bazel 7.2.0 to fetch ruff using http_archive due to a Bazel bug present before that. |
Alex - At present the version check produces a failure on all platforms if a windows binary is referenced in the manifest and the version is less than 7.1. Instead, we could change it so that the version check only fails on windows platform, and lower versions are tolerated on other platforms. I can see plusses and minuses of that approach... what do you think? |
thanks @mark-thm - I already have a re-implementation of download_and_extract due to that bug https://github.com/aspect-build/rules_lint/blob/562b84bdb00f076658fd94483a765303f671a07e/lint/ruff.bzl#L208-L220 @peakschris yeah I think we need to relax the |
@alexeagle there is a fix in #50 |
Support windows files and archives in lockfiles.
Limitations:
startup --windows_enable_symlinks
common --enable_runfiles
Validations: