-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Rules_go tests are failing on Windows with Bazel 1.0 #9995
Comments
@dslomov This is probably a release blocker for 1.0.1, but I'm still investigating the true culprit. |
b7f5605 is probably the culprit. |
But I found Bazel@HEAD didn't fail, so there must be a commit after 1.0 that already fixed the problem. |
/cc related parties |
I can just confirm this happening for me as well. Occationally on my local machine, but every time on the server. |
Should this block 1.1? (#9982) |
Yes, although this issue is not happening from HEAD since b698e20, but I don't think that's a proper fix. |
I've seen this bug on local builds too. I have no stable repro, but once it hits, it stays; you must remove the ".rawproto" file to fix it. |
I have a stable reproduce locally and found a fix for this. Sending a CL now. |
renameTo is sometimes flaky on Windows, moveFile is a more robust implementation. Fixes #9995 RELNOTES: None PiperOrigin-RevId: 274539649
The mv there is supposed to be atomic, moveFile isn't. Can we find another way to work around the issue? |
Reopening because of a rollback: ac99c29 |
@meteorcloudy I wanted to follow up on your original comment:
Is there a way that rules_go tests can invoke the version of Bazel being tested? From an example test log, I see that bazel is invoked directly as I remember running into an issue like this a long time ago back on Jenkins, and there used to be a |
So currently, we set |
Signed-off-by: Tomasz Strejczek <[email protected]>
Why was this fix not included in 1.1? :( Edit: It seems like the fix is in. If Bazel crashes before "deleteAtExit" happens, this unrecoverable error (or manual deletion is required) happens. |
618e5a2 is included in 1.1, the |
I just did a quick test in Bazel 1.1 on Windows:
|
|
@ozio85 Are you sure you are using 1.1? I don't have this problem when I tried it. |
I too can run bazel, you have to run an actual command, like build or clean. Edit: clean seems to work though.. Edit 2: Hmm.. after running clean, it seems like it is working again. I will keep investigating if it has something todo with first running 0.29.1, then 1.1.0 |
My error! I had by mistake uploaded Bazel 1.0.0 to our artifactory, but named it Bazel 1.1.0 .. so i was running 1.1.0 locally, but the server ran 1.0.0..! Sorry for the trouble! |
No worries at all, glad it worked! \o/ |
Fixes bazelbuild/bazel#9995 RELNOTES: None PiperOrigin-RevId: 274772226
*** Reason for rollback *** This operation is supposed to be atomic. The windows flakiness should be addressed more directly. *** Original change description *** Use FileSystemUtils.moveFile instead of renameTo function of Path renameTo is sometimes flaky on Windows, moveFile is a more robust implementation. Fixes bazelbuild/bazel#9995 RELNOTES: None PiperOrigin-RevId: 274606746
https://buildkite.com/bazel/rules-go-golang/builds/1491
Bazel 1.0 crashes inside the test due to some permission denied error.
We didn't catch this in downstream test because the rules_go tests invoke
bazel
fromPATH
. On CI, it would actually be Bazelisk, but Bazelisk always points to the latest stable version instead of using Bazel@HEAD.The text was updated successfully, but these errors were encountered: