Repository navigation
Add Windows ARM32 buildbot #80692
Description
Activity
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?
- added3.8 (EOL)end of lifeend of lifebuildThe build process and cross-buildThe build process and cross-buildtype-featureA feature request or enhancementA feature request or enhancement
on Apr 2, 2019 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).
2 remaining items
I manually restarted and merged the stalled 3.8 backport for 3.8.0b4. Can this issue now be closed?
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?
- addedpendingThe issue will be closed if no feedback is providedThe issue will be closed if no feedback is provided
on May 20, 2022 Yes, I think so.
- removedpendingThe issue will be closed if no feedback is providedThe issue will be closed if no feedback is provided
on May 20, 2022
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: