On Thu, 2014-12-11 at 10:04 -0500, Summers Pittman wrote:
On 12/11/2014 09:46 AM, Karel Piwko wrote:
> Hi Passos,
>
> have you enabled XVnc / Framebuffer on Jenkins? It looks that it might
> be related to the log output.
>
> If you have issues with Android SDK version and/or applying any
> configuration to existing installation, I'd suggest to use Arquillian
> Gradle Spacelift, which is able to bring Android SDK runtime there for
> you very cheaply. Stefan has automated testsuite for our Android
> ftesting tool that way, so if you have a Linux machine (adding support
> for Mac OS X should be pretty easy), you just need to clone and run
> Gradle.
And port the project to Gradle from Maven.
Well, not really, Gradle actually calls Maven, so the project itself
stays unchanged.
>
>
https://github.com/arquillian/arquillian-droidium/tree/master/tests
>
> Maybe it could be reused for Android integration tests?
>
> Also I'd suggest not to use ARMv7 ABI but x86 based one. For most CI
> setups ARMv7 means a VM in VM and that is terribly slow unless you have
> nested VM support in both HW and SW - which you most likely don't
> have ;-)
x86 has the same problem unless the environment has KVM installed. I
know Travis CI does not and I know that in all of CloudBees' docs it
refers to the arm emulator instead of using x86.
Thanks, that's a very valuable piece of information.
>
> Karel
We've also got the build running in Travis again by being much smarter
about when we start and stop the emulator and project compiling.
Sweet!
>
> On Mon, 2014-12-08 at 13:59 -0200, Daniel Passos wrote:
>> Hi All,
>>
>>
>> The Android team has been working on resolving a travis build issue
>> last week (and part of weekend) with travis-ci[1][2]. I has been
>> testing with proting the build to cloudbees[3][4].
>>
>>
>> travis-ci:
>>
>>
>> In Travis the VM is running out of memory and getting killed. We fixed
>> this by starting the emulator after compiling and I was able to make
>> it pass 2 times[5][6], but when a PR[7] for AG was sent, we were back
>> to the old problem[8] (travis-ci killed our build, because it's using
>> a lot of memory)
>>
>>
>> CloudBees:
>>
>>
>> We are having trouble running the emulator[9] on CloudBees ([android]
>> Emulator did not appear to start; giving up). We found a fix[10] but
>> are not sure if we can apply it on CloudBees
>>
>>
>> [1]
>>
https://travis-ci.org/danielpassos/aerogear-android-security/builds
>> [2]
https://travis-ci.org/secondsun/aerogear-android-security/builds
>> [3]
https://aerogear.ci.cloudbees.com/job/aerogear-android-security
>> [4]
https://aerogear.ci.cloudbees.com/job/aerogear-android-pipe
>> [5]
>>
https://travis-ci.org/danielpassos/aerogear-android-security/builds/43219446
>> [6]
>>
https://travis-ci.org/danielpassos/aerogear-android-security/builds/43256877
>> [7]
https://github.com/aerogear/aerogear-android-security/pull/17
>> [8]
>>
https://travis-ci.org/aerogear/aerogear-android-security/builds/43295194
>> [9]
>>
https://aerogear.ci.cloudbees.com/job/aerogear-android-pipe/6/jdk=openjdk...
>> [10]:
>>
http://stackoverflow.com/questions/19349222/jenkins-android-emulator-emul...
>>
>>
>> -- Passos
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev