I have an unused mac mini, so I installed Jenkins on it, and I'm trying to configure it so that it is always running monkey tests on our latest Android build. I can't find a way to do that though. I've found the Android Emulator Plugin which allows for the booting of an emulator and then running a Monkey Test on the build, but it only seems to be configurable for a certain number of events, not time based.
The ideal Jenkins configuration would poll a git server. When it sees a new commit on a specific branch, it would build the APK, run the emulator, and then start the monkey test. I'm sure crashes would happen, and every time a crash happens the test should restart. It should continue running like this indefinitely. Then when a new commit is detected, it would shut down the emulator, and start the build all over again.
Are there any creative ways that a Jenkins build could be configured to continually run monkey tests?
Related
I used to run sts suite by executing 'run sts-engbuid' on a Android 10 device and it worked well. Recently I am trying to run sts test suite on android 11 but it complains that I can't use the command 'run sts-engbuild' to start sts since it is depreciated. It asks me to run sts-dynamic-incremental even though the README file still asks user to run the sts in the old way. Has anyone experience with this?
//Farshid
I have a m1 macbook air, when I try compile the app for android a Gradle daemon tries to start, however sometimes (very often) it will hang:
If I quit the process (via Cmd + C) and try to build the app again, then I get a message one gradle daemon cannot be re-used because it's busy and another one tries to start, which also hangs...
It's super annoying, anyone else facing this problem? I'm using azul JDK (because it runs native on arm), but I don't think this is a problem with java
When I run ./gradlew --status that also hangs, the only solution seems to restart my machine a bunch of times
As it turns out the issue was Raycast, I started vscode from a script run by it (and ran the build command from the integrated vscode terminal), it seems gradle pipes the output of the daemons through the parent process and raycast doesn't play nicely with this model.
There 2 workarounds:
Don't call gradle/android build from any subprocess (in my case raycast -> vscode), just a plain terminal will work
Kill the parent process (again in my case raycast) before running the build command
I'm following some tutorial online on pushing kivy files to an android phone. The command:
buildozer android debug deploy run
finishes successfully without any errors, everything checks out fine. Uploading it to my phone, its no where to be found. Even after adding run to the end of the command, my phone just sits idle and nothing happens. Does anyone happen to know where to go to test the app?
buildozer android debug deploy run actually works as intended on my Kivy 2.0.0/buildozer 1.2.0 install, while buildozer android debug logcat deploy run just runs logcat without deploying or running anything.
Anyway, this "alternative" approach to the problem works as well if you don't want to rely completely on buildozer.
Im trying to generate an APK to test my android build, it used to work before, i dont know what went wrong that it stopped working, whenever i try to run on device either on android studio or my own device, it does not build even though its error clean. App actually installs, but when its about to run it closes down and this message appears
Heres what i got from checking the logcat on Android Studio: https://imgur.com/a/FdE4WMo
Try uninstalling the app from the device and then run it again.
The dev / debug build uses an encryption key that's specific to the machine so I think that maybe you are trying to install a different app over the original one?
I have set up a Jenkins job for building my android project in the following steps:
SSHing to a ubuntu machine. I set it up with the SDK, java, gradle, etc.
Cloning my source code
Building the apk using "./gradlew assembleRelease"
Deploying it or emailing to me (A step after apk building, customizable)
However, the SSH tunnel closes to my remote machine during some steps in the android building process, like when the following module builds:
:app:transformClassesWithDexForDevRelease
I am looking for a way to keep the SSH tunnel ON so that the building command does not exist. I tried to run the command using nohup but still does the same.
Any help or suggestions will be greatly appreciated.
EDIT:
I was able to go pass the ssh issue by making a small login machine changes as well, by adding
Host*
ServerAliveInterval 600
However, following that I added --stacktrace flag and that would give me the following response:
org.gradle.launcher.daemon.client.DaemonDisappearedException: Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed) at
org.gradle.launcher.daemon.client.DaemonClient.handleDaemonDisappearance(DaemonClient.java:222)
It seems very odd because this error never appears when I build by directly logging onto the remote machine. It only happens when the build is triggered using Jenkins. Something seems to be killing the Gradle daemon because the JVM settings seem fine. Maybe the ssh detachment is still happening but at a different point in the process than the one I was earlier seeing.
Try opening ssh connection to your ubuntu slave manually, then try increasing the connection timeout for the ssh server configurations ( /etc/ssh/ssh_config ) by configuring the keep alive parameters as shown in example bellow:
# activates the keep alive verification (default is Yes)
# you could just set this to No but it would risk keeping ghost ssh sessions
TCPKeepAlive Yes
# sets the keep alive interval (in seconds) - this will send one keep alive per minute
ClientAliveInterval 60
# Sets the number of client alive messages which may be sent without sshd receiving any messages back
ClientAliveCountMax 10
This means that sshd will send one client alive per minute and will wait 10 minutes for a client response before closing ssh session.
Assuming that your whole jenkins build (checkout + installing stuff + gradle build) takes less then 10 minutes it should work fine.