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
x/mobile: get Android builders passing on x/mobile #30482
Comments
I will fix the test failures, but their root cause is trickier: the android builders run with GOOS=android which means that the tests run on the device. So we don't get to run the interesting tests (host builds an Android apk, pushes it to the device and runs it). So the builder should (also?) somehow run with GOOS=$GOHOSTOS for the x/mobile repository. What do you think? |
I guess we could special case that. I'd reuse the existing buildlets & just run "go test" twice with different env. The host tools should already be compiled from the make.bash. Can you verify that works in a local docker container? That is: a GOOS=android make.bash followed by an x/mobile GOOS=linux go test? |
Change https://golang.org/cl/164740 mentions this issue: |
Updates golang/go#30482 Change-Id: I198dd40dfdb86b20e681c373141754680351e82f Reviewed-on: https://go-review.googlesource.com/c/164740 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Elias Naur <mail@eliasnaur.com>
Works for me with a variant of the Dockerfile from https://go-review.googlesource.com/c/build/+/164658. |
Change https://golang.org/cl/164660 mentions this issue: |
Change https://golang.org/cl/164799 mentions this issue: |
…ached When running GOOS=android go test <pkg>, the go tool will build the test(s) for Android and run it through the exec wrapper. The exec wrappers takes care of pushing the binary to the device and running it. That's how the normal builder with an Android device attached works: setting GOOS=android. Some x/mobile tests uses the Android SDK and then use an Android specific way to run integration tests with Java. Those tests don't run on GOOS=android. To solve that dilemma, define a special builder without GOOS=android set and use it (only) for x/mobile. Then, disable the GOOS=android builder for x/mobile to avoid wasting device time better spent on the main repository. Similar to CL 164740. While here, correct two GOHOSTOS values and rename the existing android builders to match the GOOS-GOARCH-suffix form. Updates golang/go#30482 Change-Id: I3712584c62c3765d5605cccb642aa6f119826ae8 Reviewed-on: https://go-review.googlesource.com/c/build/+/164660 Run-TryBot: Elias Naur <mail@eliasnaur.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Some x/mobile tests are designed to run from a host with a device or emulator attached. Some fail if they run directly from a device, which is the case when GOOS=android. Fix the tests by skipping them or adjusting them to work on GOOS=android. Remove gomobile environment naïve variable expansion for $HOME; on Android devices HOME=/ so every path separator is replaced with $HOME. Fixes golang/go#30482 Change-Id: I553e708226922f6284163f0b7d7b1011a9502e34 Reviewed-on: https://go-review.googlesource.com/c/164799 Run-TryBot: Elias Naur <mail@eliasnaur.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Some x/mobile tests are designed to run from a host with a device or emulator attached. Some fail if they run directly from a device, which is the case when GOOS=android. Fix the tests by skipping them or adjusting them to work on GOOS=android. Remove gomobile environment naïve variable expansion for $HOME; on Android devices HOME=/ so every path separator is replaced with $HOME. Fixes golang/go#30482 Change-Id: I553e708226922f6284163f0b7d7b1011a9502e34 Reviewed-on: https://go-review.googlesource.com/c/164799 Run-TryBot: Elias Naur <mail@eliasnaur.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
We now have x/mobile running on Android emulators on GCE and the first results are in:
https://build.golang.org/log/63ae018cd1092f5750d53441636171d48aeb8836
Looks like there's some cleanup to do, but not terrible.
We don't yet have those being used for mobile trybots, but we should.
The text was updated successfully, but these errors were encountered: