-
-
Notifications
You must be signed in to change notification settings - Fork 31.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
Add Windows ARM32 buildbot #80692
Comments
Zachary Ware suggested I create an issue to discuss this: I've started a worker using the worker name monson-win-arm32 and the password provided. I think it is waiting for a change, there were no errors, but it didn't print anything. Also, I don’t see anything in the list of builders that looks like it would be windows arm32, and it's not showing in the list of workers. I'm looking at tools/buildbot/test.bat and it seems like it might be a good place to use SSH to run the test on arm32 device, but I'm not clear on where it is called from or what the best way to detect that project is being cross-compiled. Should I add an "-arm32" switch here? |
Going to leave this in commit review for a bit, in case hitting merge suddenly flushes out some reviews :) |
Paul - looks like there's a timeout being hit due to lack of output. Any ideas? |
I've been investigating issues with test failures on my Windows buildbots seemingly not showing up in the master's web interface (but just showing warnings), and it appears likely due to this change. For example, test_urllib (a test problem from bpo-36948) was failing but only appeared as a warning (the first such case on my Win10 builder for example is https://buildbot.python.org/all/#/builders/3/builds/2661). This change appears to force the exit code of test.bat to be successful (0) regardless of the results of the test run, thus obscuring any test failures from a parent process such as the buildbot. As an aside, it also looks like any failures along the new arm32ssh branch would be obscured, assuming that the ssh operation would otherwise have propagated the remote exit code. I think just leaving off the exit code (so just "exit /b") should propagate the rt.bat result properly. Or, a goto to a label at the end of the file and letting it exit naturally would mimic the prior behavior. |
I did a quick test and it looks like exit /b %ERRORLEVEL% will propagate the exit code. |
Yeah, I think you're right. It looks like without an explicit code, it won't propagate the result as the exit code of cmd itself for those cases where cmd does exit (which would include the buildbots). |
I manually restarted and merged the stalled 3.8 backport for 3.8.0b4. Can this issue now be closed? |
I spoke too soon. It appears there's another open backport PR-14244 for this issue that needs some conflict resolution to be merged. |
Can this be closed? |
Yes, I think so. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: