Anyone have experience with Android continuous integration?


(Yaw Anokwa) #1

Hi all,

I'd like to get automated nightly builds for ODK Collect and I'd love
to hear from folks who've used continuous integration and testing on
Android apps.

I'm guessing the folks at Dimagi, Kobo, SurveyCTO, Ona, and ELMO all
have some experience here. What platform did you use? Would you
recommend it?

Thanks,

Yaw


(Christopher Robert) #2

Hi Yaw,

We automate builds with Jenkins on AWS EC2. However, we have always built
our Android apk separately for a couple of reasons:

  1. We wanted to more tightly control the build environment, including
    the version of Java.
  2. We wanted to guard the key we used to sign the apk closely.
  3. And we ran into trouble with the Android SDK on EC2 (something about
    x64 EC2 environments).

For 3, there are blog posts like this one
https://arpitonline.com/2014/01/05/setting-up-a-continuous-build-and-integration-environment-for-android-with-aws-jenkins-and-github/,
AWS seems to have embraced Jenkins
http://docs.aws.amazon.com/devicefarm/latest/developerguide/continuous-integration-jenkins-plugin.html,
and with their mobile SDK https://aws.amazon.com/mobile/sdk/ AWS is
clearly trying to accommodate mobile developers. So I suspect that if we
went back to try it again, everything would be fine.

As for 1 and 2, I think that those are less of a concern now. Back in 2013
we were a bit less comfortable with our EC2/Linux skills and so we
preferred building with Maven on OSX. But now I think that we could have a
well-controlled environment on which we wouldn't mind housing our private
key.

So, I'd recommend Jenkins on EC2 -- though I will say that it's not
uncommon for Jenkins to get OOM errors and need to be restarted. We keep
bumping up the memory on our dev server, but nothing seems to be quite what
Jenkins wants. (I think that it wants a large memory swap file, but we
don't have a local drive on that machine and so don't have a memory swap
configured.)

Best,

Chris

ยทยทยท On Tue, Aug 23, 2016 at 8:21 AM Yaw Anokwa wrote:

Hi all,

I'd like to get automated nightly builds for ODK Collect and I'd love
to hear from folks who've used continuous integration and testing on
Android apps.

I'm guessing the folks at Dimagi, Kobo, SurveyCTO, Ona, and ELMO all
have some experience here. What platform did you use? Would you
recommend it?

Thanks,

Yaw

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(Sam Sudar) #3

I've used Travis github integration in the past for a small project:

You can see example build output here:

https://travis-ci.org/srsudar/odk-sms-bridge

I found it easy to work with. I believe I was building per commit, not
nightly. It isn't a complicated project, however, and I don't know what
it's like setting it up for publishing the nightly builds to a location.

I have no experience building signed APKs automatically, so I can't speak
to Chris's points about key locations or automatic signing.

ยทยทยท On Tue, Aug 23, 2016 at 5:37 AM, Christopher Robert wrote:

Hi Yaw,

We automate builds with Jenkins on AWS EC2. However, we have always built
our Android apk separately for a couple of reasons:

  1. We wanted to more tightly control the build environment, including
    the version of Java.
  2. We wanted to guard the key we used to sign the apk closely.
  3. And we ran into trouble with the Android SDK on EC2 (something
    about x64 EC2 environments).

For 3, there are blog posts like this one
https://arpitonline.com/2014/01/05/setting-up-a-continuous-build-and-integration-environment-for-android-with-aws-jenkins-and-github/,
AWS seems to have embraced Jenkins
http://docs.aws.amazon.com/devicefarm/latest/developerguide/continuous-integration-jenkins-plugin.html,
and with their mobile SDK https://aws.amazon.com/mobile/sdk/ AWS is
clearly trying to accommodate mobile developers. So I suspect that if we
went back to try it again, everything would be fine.

As for 1 and 2, I think that those are less of a concern now. Back in 2013
we were a bit less comfortable with our EC2/Linux skills and so we
preferred building with Maven on OSX. But now I think that we could have a
well-controlled environment on which we wouldn't mind housing our private
key.

So, I'd recommend Jenkins on EC2 -- though I will say that it's not
uncommon for Jenkins to get OOM errors and need to be restarted. We keep
bumping up the memory on our dev server, but nothing seems to be quite what
Jenkins wants. (I think that it wants a large memory swap file, but we
don't have a local drive on that machine and so don't have a memory swap
configured.)

Best,

Chris

On Tue, Aug 23, 2016 at 8:21 AM Yaw Anokwa yanokwa@nafundi.com wrote:

Hi all,

I'd like to get automated nightly builds for ODK Collect and I'd love
to hear from folks who've used continuous integration and testing on
Android apps.

I'm guessing the folks at Dimagi, Kobo, SurveyCTO, Ona, and ELMO all
have some experience here. What platform did you use? Would you
recommend it?

Thanks,

Yaw

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(Jeff Beorse) #4

Hi Yaw,

I'm not sure how familiar you are with what we're doing in ODK 2.0, but
we're using Jenkins to decent success. I'd echo Chris's endorsement of
Jenkins on EC2.

Jenkins is pretty powerful and gives you a lot of control over the details
of your build. There are vast amounts of plugins, including integration
with Github, Gradle, Android Emulators, JaCoCo, etc. We're running custom
scripts to handle copying file dependencies, automating multi-emulator test
suites, controlling slave systems for UI tests, publishing binaries through
Artifactory, graphing code coverage summaries, and more. We're running
automatic builds on each push to the development or demo branches,
including building signed APKs. We still build our master branch release
binaries by hand because we like to do some hand testing before the real
release, but we could easily build them with Jenkins too.

Its not all perfect, of course. As Chris implied, Jenkins can be pretty
finicky. With each version bump we seem to have to fix our github
integration. Documentation can be spotty depending on the plugin. Emulators
misbehave, though this is probably more Google's fault.

I don't have any experience with Travis, so I can't compare the two
systems. All I can say is we've had an overall positive experience with
Jenkins.

Regards,
Jeff

ยทยทยท On Tue, Aug 23, 2016 at 8:50 AM, Sam Sudar wrote:

I've used Travis github integration in the past for a small project:

https://github.com/srsudar/odk-sms-bridge

You can see example build output here:

https://travis-ci.org/srsudar/odk-sms-bridge

I found it easy to work with. I believe I was building per commit, not
nightly. It isn't a complicated project, however, and I don't know what
it's like setting it up for publishing the nightly builds to a location.

I have no experience building signed APKs automatically, so I can't speak
to Chris's points about key locations or automatic signing.

On Tue, Aug 23, 2016 at 5:37 AM, Christopher Robert <crobert@surveycto.com wrote:

Hi Yaw,

We automate builds with Jenkins on AWS EC2. However, we have always built
our Android apk separately for a couple of reasons:

  1. We wanted to more tightly control the build environment, including
    the version of Java.
  2. We wanted to guard the key we used to sign the apk closely.
  3. And we ran into trouble with the Android SDK on EC2 (something
    about x64 EC2 environments).

For 3, there are blog posts like this one
https://arpitonline.com/2014/01/05/setting-up-a-continuous-build-and-integration-environment-for-android-with-aws-jenkins-and-github/,
AWS seems to have embraced Jenkins
http://docs.aws.amazon.com/devicefarm/latest/developerguide/continuous-integration-jenkins-plugin.html,
and with their mobile SDK https://aws.amazon.com/mobile/sdk/ AWS is
clearly trying to accommodate mobile developers. So I suspect that if we
went back to try it again, everything would be fine.

As for 1 and 2, I think that those are less of a concern now. Back in
2013 we were a bit less comfortable with our EC2/Linux skills and so we
preferred building with Maven on OSX. But now I think that we could have a
well-controlled environment on which we wouldn't mind housing our private
key.

So, I'd recommend Jenkins on EC2 -- though I will say that it's not
uncommon for Jenkins to get OOM errors and need to be restarted. We keep
bumping up the memory on our dev server, but nothing seems to be quite what
Jenkins wants. (I think that it wants a large memory swap file, but we
don't have a local drive on that machine and so don't have a memory swap
configured.)

Best,

Chris

On Tue, Aug 23, 2016 at 8:21 AM Yaw Anokwa yanokwa@nafundi.com wrote:

Hi all,

I'd like to get automated nightly builds for ODK Collect and I'd love
to hear from folks who've used continuous integration and testing on
Android apps.

I'm guessing the folks at Dimagi, Kobo, SurveyCTO, Ona, and ELMO all
have some experience here. What platform did you use? Would you
recommend it?

Thanks,

Yaw

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(Matt Berg) #5

We use Jenkins and Drone. Jenkins I believe offers a free service for OS
projects if you are ok with waiting for your builds in a queue.

Matt

ยทยทยท On Aug 23, 2016 1:34 PM, "Jeffrey Beorse" wrote:

Hi Yaw,

I'm not sure how familiar you are with what we're doing in ODK 2.0, but
we're using Jenkins to decent success. I'd echo Chris's endorsement of
Jenkins on EC2.

Jenkins is pretty powerful and gives you a lot of control over the details
of your build. There are vast amounts of plugins, including integration
with Github, Gradle, Android Emulators, JaCoCo, etc. We're running custom
scripts to handle copying file dependencies, automating multi-emulator test
suites, controlling slave systems for UI tests, publishing binaries through
Artifactory, graphing code coverage summaries, and more. We're running
automatic builds on each push to the development or demo branches,
including building signed APKs. We still build our master branch release
binaries by hand because we like to do some hand testing before the real
release, but we could easily build them with Jenkins too.

Its not all perfect, of course. As Chris implied, Jenkins can be pretty
finicky. With each version bump we seem to have to fix our github
integration. Documentation can be spotty depending on the plugin. Emulators
misbehave, though this is probably more Google's fault.

I don't have any experience with Travis, so I can't compare the two
systems. All I can say is we've had an overall positive experience with
Jenkins.

Regards,
Jeff

On Tue, Aug 23, 2016 at 8:50 AM, Sam Sudar sudar.sam@gmail.com wrote:

I've used Travis github integration in the past for a small project:

https://github.com/srsudar/odk-sms-bridge

You can see example build output here:

https://travis-ci.org/srsudar/odk-sms-bridge

I found it easy to work with. I believe I was building per commit, not
nightly. It isn't a complicated project, however, and I don't know what
it's like setting it up for publishing the nightly builds to a location.

I have no experience building signed APKs automatically, so I can't speak
to Chris's points about key locations or automatic signing.

On Tue, Aug 23, 2016 at 5:37 AM, Christopher Robert < crobert@surveycto.com> wrote:

Hi Yaw,

We automate builds with Jenkins on AWS EC2. However, we have always
built our Android apk separately for a couple of reasons:

  1. We wanted to more tightly control the build environment,
    including the version of Java.
  2. We wanted to guard the key we used to sign the apk closely.
  3. And we ran into trouble with the Android SDK on EC2 (something
    about x64 EC2 environments).

For 3, there are blog posts like this one
https://arpitonline.com/2014/01/05/setting-up-a-continuous-build-and-integration-environment-for-android-with-aws-jenkins-and-github/,
AWS seems to have embraced Jenkins
http://docs.aws.amazon.com/devicefarm/latest/developerguide/continuous-integration-jenkins-plugin.html,
and with their mobile SDK https://aws.amazon.com/mobile/sdk/ AWS is
clearly trying to accommodate mobile developers. So I suspect that if we
went back to try it again, everything would be fine.

As for 1 and 2, I think that those are less of a concern now. Back in
2013 we were a bit less comfortable with our EC2/Linux skills and so we
preferred building with Maven on OSX. But now I think that we could have a
well-controlled environment on which we wouldn't mind housing our private
key.

So, I'd recommend Jenkins on EC2 -- though I will say that it's not
uncommon for Jenkins to get OOM errors and need to be restarted. We keep
bumping up the memory on our dev server, but nothing seems to be quite what
Jenkins wants. (I think that it wants a large memory swap file, but we
don't have a local drive on that machine and so don't have a memory swap
configured.)

Best,

Chris

On Tue, Aug 23, 2016 at 8:21 AM Yaw Anokwa yanokwa@nafundi.com wrote:

Hi all,

I'd like to get automated nightly builds for ODK Collect and I'd love
to hear from folks who've used continuous integration and testing on
Android apps.

I'm guessing the folks at Dimagi, Kobo, SurveyCTO, Ona, and ELMO all
have some experience here. What platform did you use? Would you
recommend it?

Thanks,

Yaw

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(Yaw Anokwa) #6

This is great info. Looks like Jenkins is what most are using. My
light reading is that their Android integration isn't amazing.

Has anyone tried CircleCI? It visually looks better, has reportedly
better Android support, and is free for OSS.

ยทยทยท On Tue, Aug 23, 2016 at 10:53 PM, Matt Berg wrote: > We use Jenkins and Drone. Jenkins I believe offers a free service for OS > projects if you are ok with waiting for your builds in a queue. > > Matt > > > On Aug 23, 2016 1:34 PM, "Jeffrey Beorse" wrote: >> >> Hi Yaw, >> >> I'm not sure how familiar you are with what we're doing in ODK 2.0, but >> we're using Jenkins to decent success. I'd echo Chris's endorsement of >> Jenkins on EC2. >> >> Jenkins is pretty powerful and gives you a lot of control over the details >> of your build. There are vast amounts of plugins, including integration with >> Github, Gradle, Android Emulators, JaCoCo, etc. We're running custom scripts >> to handle copying file dependencies, automating multi-emulator test suites, >> controlling slave systems for UI tests, publishing binaries through >> Artifactory, graphing code coverage summaries, and more. We're running >> automatic builds on each push to the development or demo branches, including >> building signed APKs. We still build our master branch release binaries by >> hand because we like to do some hand testing before the real release, but we >> could easily build them with Jenkins too. >> >> Its not all perfect, of course. As Chris implied, Jenkins can be pretty >> finicky. With each version bump we seem to have to fix our github >> integration. Documentation can be spotty depending on the plugin. Emulators >> misbehave, though this is probably more Google's fault. >> >> I don't have any experience with Travis, so I can't compare the two >> systems. All I can say is we've had an overall positive experience with >> Jenkins. >> >> Regards, >> Jeff >> >> On Tue, Aug 23, 2016 at 8:50 AM, Sam Sudar wrote: >>> >>> I've used Travis github integration in the past for a small project: >>> >>> https://github.com/srsudar/odk-sms-bridge >>> >>> You can see example build output here: >>> >>> https://travis-ci.org/srsudar/odk-sms-bridge >>> >>> I found it easy to work with. I believe I was building per commit, not >>> nightly. It isn't a complicated project, however, and I don't know what >>> it's like setting it up for publishing the nightly builds to a location. >>> >>> I have no experience building signed APKs automatically, so I can't speak >>> to Chris's points about key locations or automatic signing. >>> >>> On Tue, Aug 23, 2016 at 5:37 AM, Christopher Robert wrote: >>>> >>>> Hi Yaw, >>>> >>>> We automate builds with Jenkins on AWS EC2. However, we have always >>>> built our Android apk separately for a couple of reasons: >>>> >>>> We wanted to more tightly control the build environment, including the >>>> version of Java. >>>> We wanted to guard the key we used to sign the apk closely. >>>> And we ran into trouble with the Android SDK on EC2 (something about x64 >>>> EC2 environments). >>>> >>>> For 3, there are blog posts like this one, AWS seems to have embraced >>>> Jenkins, and with their mobile SDK AWS is clearly trying to accommodate >>>> mobile developers. So I suspect that if we went back to try it again, >>>> everything would be fine. >>>> >>>> As for 1 and 2, I think that those are less of a concern now. Back in >>>> 2013 we were a bit less comfortable with our EC2/Linux skills and so we >>>> preferred building with Maven on OSX. But now I think that we could have a >>>> well-controlled environment on which we wouldn't mind housing our private >>>> key. >>>> >>>> So, I'd recommend Jenkins on EC2 -- though I will say that it's not >>>> uncommon for Jenkins to get OOM errors and need to be restarted. We keep >>>> bumping up the memory on our dev server, but nothing seems to be quite what >>>> Jenkins wants. (I think that it wants a large memory swap file, but we don't >>>> have a local drive on that machine and so don't have a memory swap >>>> configured.) >>>> >>>> Best, >>>> >>>> Chris >>>> >>>> On Tue, Aug 23, 2016 at 8:21 AM Yaw Anokwa wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I'd like to get automated nightly builds for ODK Collect and I'd love >>>>> to hear from folks who've used continuous integration and testing on >>>>> Android apps. >>>>> >>>>> I'm guessing the folks at Dimagi, Kobo, SurveyCTO, Ona, and ELMO all >>>>> have some experience here. What platform did you use? Would you >>>>> recommend it? >>>>> >>>>> Thanks, >>>>> >>>>> Yaw >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "ODK Developers" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to opendatakit-developers+unsubscribe@googlegroups.com. >>>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "ODK Developers" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to opendatakit-developers+unsubscribe@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "ODK Developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to opendatakit-developers+unsubscribe@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "ODK Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to opendatakit-developers+unsubscribe@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "ODK Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to opendatakit-developers+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout.

(Brent Atkinson) #7

Hi,

I have used Jenkins and Travis. I haven't used CircleCI, but it seems
extremely similar in spirit to Travis (connect your GitHub project and go,
add YAML for customization).

In my experience, the biggest difference between Jenkins and these other
tools is that it is extremely flexible in terms of deployment. You can
setup a single master on your machine, a massive master/slave setup in the
cloud, or use as-a-service with something like CloudBees. My experience
with CIaaS is that it's a perfect free option for projects that fit well
within the templates, but once you start needing more exotic configurations
not being able to fully control the environment makes them less attractive.

Brent

ยทยทยท On Wednesday, August 24, 2016 at 4:01:54 AM UTC-4, Yaw Anokwa wrote: > > This is great info. Looks like Jenkins is what most are using. My > light reading is that their Android integration isn't amazing. > > Has anyone tried CircleCI? It visually looks better, has reportedly > better Android support, and is free for OSS. > > On Tue, Aug 23, 2016 at 10:53 PM, Matt Berg <mlb...@gmail.com > wrote: > > We use Jenkins and Drone. Jenkins I believe offers a free service for > OS > > projects if you are ok with waiting for your builds in a queue. > > > > Matt > > > > > > On Aug 23, 2016 1:34 PM, "Jeffrey Beorse" <jbe...@cs.washington.edu > wrote: > >> > >> Hi Yaw, > >> > >> I'm not sure how familiar you are with what we're doing in ODK 2.0, but > >> we're using Jenkins to decent success. I'd echo Chris's endorsement of > >> Jenkins on EC2. > >> > >> Jenkins is pretty powerful and gives you a lot of control over the > details > >> of your build. There are vast amounts of plugins, including integration > with > >> Github, Gradle, Android Emulators, JaCoCo, etc. We're running custom > scripts > >> to handle copying file dependencies, automating multi-emulator test > suites, > >> controlling slave systems for UI tests, publishing binaries through > >> Artifactory, graphing code coverage summaries, and more. We're running > >> automatic builds on each push to the development or demo branches, > including > >> building signed APKs. We still build our master branch release binaries > by > >> hand because we like to do some hand testing before the real release, > but we > >> could easily build them with Jenkins too. > >> > >> Its not all perfect, of course. As Chris implied, Jenkins can be pretty > >> finicky. With each version bump we seem to have to fix our github > >> integration. Documentation can be spotty depending on the plugin. > Emulators > >> misbehave, though this is probably more Google's fault. > >> > >> I don't have any experience with Travis, so I can't compare the two > >> systems. All I can say is we've had an overall positive experience with > >> Jenkins. > >> > >> Regards, > >> Jeff > >> > >> On Tue, Aug 23, 2016 at 8:50 AM, Sam Sudar <suda...@gmail.com > wrote: > >>> > >>> I've used Travis github integration in the past for a small project: > >>> > >>> https://github.com/srsudar/odk-sms-bridge > >>> > >>> You can see example build output here: > >>> > >>> https://travis-ci.org/srsudar/odk-sms-bridge > >>> > >>> I found it easy to work with. I believe I was building per commit, not > >>> nightly. It isn't a complicated project, however, and I don't know > what > >>> it's like setting it up for publishing the nightly builds to a > location. > >>> > >>> I have no experience building signed APKs automatically, so I can't > speak > >>> to Chris's points about key locations or automatic signing. > >>> > >>> On Tue, Aug 23, 2016 at 5:37 AM, Christopher Robert <cro...@surveycto.com > wrote: > >>>> > >>>> Hi Yaw, > >>>> > >>>> We automate builds with Jenkins on AWS EC2. However, we have always > >>>> built our Android apk separately for a couple of reasons: > >>>> > >>>> We wanted to more tightly control the build environment, including > the > >>>> version of Java. > >>>> We wanted to guard the key we used to sign the apk closely. > >>>> And we ran into trouble with the Android SDK on EC2 (something about > x64 > >>>> EC2 environments). > >>>> > >>>> For 3, there are blog posts like this one, AWS seems to have embraced > >>>> Jenkins, and with their mobile SDK AWS is clearly trying to > accommodate > >>>> mobile developers. So I suspect that if we went back to try it again, > >>>> everything would be fine. > >>>> > >>>> As for 1 and 2, I think that those are less of a concern now. Back in > >>>> 2013 we were a bit less comfortable with our EC2/Linux skills and so > we > >>>> preferred building with Maven on OSX. But now I think that we could > have a > >>>> well-controlled environment on which we wouldn't mind housing our > private > >>>> key. > >>>> > >>>> So, I'd recommend Jenkins on EC2 -- though I will say that it's not > >>>> uncommon for Jenkins to get OOM errors and need to be restarted. We > keep > >>>> bumping up the memory on our dev server, but nothing seems to be > quite what > >>>> Jenkins wants. (I think that it wants a large memory swap file, but > we don't > >>>> have a local drive on that machine and so don't have a memory swap > >>>> configured.) > >>>> > >>>> Best, > >>>> > >>>> Chris > >>>> > >>>> On Tue, Aug 23, 2016 at 8:21 AM Yaw Anokwa <yan...@nafundi.com > wrote: > >>>>> > >>>>> Hi all, > >>>>> > >>>>> I'd like to get automated nightly builds for ODK Collect and I'd > love > >>>>> to hear from folks who've used continuous integration and testing on > >>>>> Android apps. > >>>>> > >>>>> I'm guessing the folks at Dimagi, Kobo, SurveyCTO, Ona, and ELMO all > >>>>> have some experience here. What platform did you use? Would you > >>>>> recommend it? > >>>>> > >>>>> Thanks, > >>>>> > >>>>> Yaw > >>>>> > >>>>> -- > >>>>> You received this message because you are subscribed to the Google > >>>>> Groups "ODK Developers" group. > >>>>> To unsubscribe from this group and stop receiving emails from it, > send > >>>>> an email to opendatakit-developers+unsubscribe@googlegroups.com > . > >>>>> For more options, visit https://groups.google.com/d/optout. > >>>> > >>>> -- > >>>> You received this message because you are subscribed to the Google > >>>> Groups "ODK Developers" group. > >>>> To unsubscribe from this group and stop receiving emails from it, > send > >>>> an email to opendatakit-developers+unsubscribe@googlegroups.com > . > >>>> For more options, visit https://groups.google.com/d/optout. > >>> > >>> > >>> -- > >>> You received this message because you are subscribed to the Google > Groups > >>> "ODK Developers" group. > >>> To unsubscribe from this group and stop receiving emails from it, send > an > >>> email to opendatakit-developers+unsubscribe@googlegroups.com > . > >>> For more options, visit https://groups.google.com/d/optout. > >> > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "ODK Developers" group. > >> To unsubscribe from this group and stop receiving emails from it, send > an > >> email to opendatakit-developers+unsubscribe@googlegroups.com > . > >> For more options, visit https://groups.google.com/d/optout. > > > > -- > > You received this message because you are subscribed to the Google > Groups > > "ODK Developers" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to opendatakit-developers+unsubscribe@googlegroups.com > . > > For more options, visit https://groups.google.com/d/optout. >

(Brent Atkinson) #8

Sorry for the noise, but reading more on CircleCI, they claim that they
allow you to do whatever you want on their environments. It probably still
means you're stuck with their starting environments, but it seems you at
least have full control over them.

Brent

ยทยทยท On Thu, Aug 25, 2016 at 10:28 AM, Brent Atkinson wrote:

Hi,

I have used Jenkins and Travis. I haven't used CircleCI, but it seems
extremely similar in spirit to Travis (connect your GitHub project and go,
add YAML for customization).

In my experience, the biggest difference between Jenkins and these other
tools is that it is extremely flexible in terms of deployment. You can
setup a single master on your machine, a massive master/slave setup in the
cloud, or use as-a-service with something like CloudBees. My experience
with CIaaS is that it's a perfect free option for projects that fit well
within the templates, but once you start needing more exotic configurations
not being able to fully control the environment makes them less attractive.

Brent

On Wednesday, August 24, 2016 at 4:01:54 AM UTC-4, Yaw Anokwa wrote:

This is great info. Looks like Jenkins is what most are using. My
light reading is that their Android integration isn't amazing.

Has anyone tried CircleCI? It visually looks better, has reportedly
better Android support, and is free for OSS.

On Tue, Aug 23, 2016 at 10:53 PM, Matt Berg mlb...@gmail.com wrote:

We use Jenkins and Drone. Jenkins I believe offers a free service for
OS
projects if you are ok with waiting for your builds in a queue.

Matt

On Aug 23, 2016 1:34 PM, "Jeffrey Beorse" jbe...@cs.washington.edu wrote:

Hi Yaw,

I'm not sure how familiar you are with what we're doing in ODK 2.0,
but

we're using Jenkins to decent success. I'd echo Chris's endorsement of
Jenkins on EC2.

Jenkins is pretty powerful and gives you a lot of control over the
details

of your build. There are vast amounts of plugins, including
integration with

Github, Gradle, Android Emulators, JaCoCo, etc. We're running custom
scripts

to handle copying file dependencies, automating multi-emulator test
suites,

controlling slave systems for UI tests, publishing binaries through
Artifactory, graphing code coverage summaries, and more. We're running
automatic builds on each push to the development or demo branches,
including

building signed APKs. We still build our master branch release
binaries by

hand because we like to do some hand testing before the real release,
but we

could easily build them with Jenkins too.

Its not all perfect, of course. As Chris implied, Jenkins can be
pretty

finicky. With each version bump we seem to have to fix our github
integration. Documentation can be spotty depending on the plugin.
Emulators

misbehave, though this is probably more Google's fault.

I don't have any experience with Travis, so I can't compare the two
systems. All I can say is we've had an overall positive experience
with

Jenkins.

Regards,
Jeff

On Tue, Aug 23, 2016 at 8:50 AM, Sam Sudar suda...@gmail.com wrote:

I've used Travis github integration in the past for a small project:

https://github.com/srsudar/odk-sms-bridge

You can see example build output here:

https://travis-ci.org/srsudar/odk-sms-bridge

I found it easy to work with. I believe I was building per commit,
not

nightly. It isn't a complicated project, however, and I don't know
what

it's like setting it up for publishing the nightly builds to a
location.

I have no experience building signed APKs automatically, so I can't
speak

to Chris's points about key locations or automatic signing.

On Tue, Aug 23, 2016 at 5:37 AM, Christopher Robert cro...@surveycto.com wrote:

Hi Yaw,

We automate builds with Jenkins on AWS EC2. However, we have always
built our Android apk separately for a couple of reasons:

We wanted to more tightly control the build environment, including
the

version of Java.
We wanted to guard the key we used to sign the apk closely.
And we ran into trouble with the Android SDK on EC2 (something about
x64

EC2 environments).

For 3, there are blog posts like this one, AWS seems to have
embraced

Jenkins, and with their mobile SDK AWS is clearly trying to
accommodate

mobile developers. So I suspect that if we went back to try it
again,

everything would be fine.

As for 1 and 2, I think that those are less of a concern now. Back
in

2013 we were a bit less comfortable with our EC2/Linux skills and so
we

preferred building with Maven on OSX. But now I think that we could
have a

well-controlled environment on which we wouldn't mind housing our
private

key.

So, I'd recommend Jenkins on EC2 -- though I will say that it's not
uncommon for Jenkins to get OOM errors and need to be restarted. We
keep

bumping up the memory on our dev server, but nothing seems to be
quite what

Jenkins wants. (I think that it wants a large memory swap file, but
we don't

have a local drive on that machine and so don't have a memory swap
configured.)

Best,

Chris

On Tue, Aug 23, 2016 at 8:21 AM Yaw Anokwa yan...@nafundi.com wrote:

Hi all,

I'd like to get automated nightly builds for ODK Collect and I'd
love

to hear from folks who've used continuous integration and testing
on

Android apps.

I'm guessing the folks at Dimagi, Kobo, SurveyCTO, Ona, and ELMO
all

have some experience here. What platform did you use? Would you
recommend it?

Thanks,

Yaw

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(Yaw Anokwa) #9

Thanks for looking into CircleCI, Brent. My gut says that we should
try it first, if that ends up sucking, we can fallback switch to
Jenkins, warts and all. Do you have the cycles to give it a try on the
Collect repo?

Yaw

ยทยทยท On Thu, Aug 25, 2016 at 2:37 PM, Brent Atkinson wrote: > Sorry for the noise, but reading more on CircleCI, they claim that they > allow you to do whatever you want on their environments. It probably still > means you're stuck with their starting environments, but it seems you at > least have full control over them. > > Brent > > On Thu, Aug 25, 2016 at 10:28 AM, Brent Atkinson wrote: >> >> Hi, >> >> I have used Jenkins and Travis. I haven't used CircleCI, but it seems >> extremely similar in spirit to Travis (connect your GitHub project and go, >> add YAML for customization). >> >> In my experience, the biggest difference between Jenkins and these other >> tools is that it is extremely flexible in terms of deployment. You can setup >> a single master on your machine, a massive master/slave setup in the cloud, >> or use as-a-service with something like CloudBees. My experience with CIaaS >> is that it's a perfect free option for projects that fit well within the >> templates, but once you start needing more exotic configurations not being >> able to fully control the environment makes them less attractive. >> >> Brent >> >> >> >> On Wednesday, August 24, 2016 at 4:01:54 AM UTC-4, Yaw Anokwa wrote: >>> >>> This is great info. Looks like Jenkins is what most are using. My >>> light reading is that their Android integration isn't amazing. >>> >>> Has anyone tried CircleCI? It visually looks better, has reportedly >>> better Android support, and is free for OSS. >>> >>> On Tue, Aug 23, 2016 at 10:53 PM, Matt Berg wrote: >>> > We use Jenkins and Drone. Jenkins I believe offers a free service for >>> > OS >>> > projects if you are ok with waiting for your builds in a queue. >>> > >>> > Matt >>> > >>> > >>> > On Aug 23, 2016 1:34 PM, "Jeffrey Beorse" wrote: >>> >> >>> >> Hi Yaw, >>> >> >>> >> I'm not sure how familiar you are with what we're doing in ODK 2.0, >>> >> but >>> >> we're using Jenkins to decent success. I'd echo Chris's endorsement of >>> >> Jenkins on EC2. >>> >> >>> >> Jenkins is pretty powerful and gives you a lot of control over the >>> >> details >>> >> of your build. There are vast amounts of plugins, including >>> >> integration with >>> >> Github, Gradle, Android Emulators, JaCoCo, etc. We're running custom >>> >> scripts >>> >> to handle copying file dependencies, automating multi-emulator test >>> >> suites, >>> >> controlling slave systems for UI tests, publishing binaries through >>> >> Artifactory, graphing code coverage summaries, and more. We're running >>> >> automatic builds on each push to the development or demo branches, >>> >> including >>> >> building signed APKs. We still build our master branch release >>> >> binaries by >>> >> hand because we like to do some hand testing before the real release, >>> >> but we >>> >> could easily build them with Jenkins too. >>> >> >>> >> Its not all perfect, of course. As Chris implied, Jenkins can be >>> >> pretty >>> >> finicky. With each version bump we seem to have to fix our github >>> >> integration. Documentation can be spotty depending on the plugin. >>> >> Emulators >>> >> misbehave, though this is probably more Google's fault. >>> >> >>> >> I don't have any experience with Travis, so I can't compare the two >>> >> systems. All I can say is we've had an overall positive experience >>> >> with >>> >> Jenkins. >>> >> >>> >> Regards, >>> >> Jeff >>> >> >>> >> On Tue, Aug 23, 2016 at 8:50 AM, Sam Sudar wrote: >>> >>> >>> >>> I've used Travis github integration in the past for a small project: >>> >>> >>> >>> https://github.com/srsudar/odk-sms-bridge >>> >>> >>> >>> You can see example build output here: >>> >>> >>> >>> https://travis-ci.org/srsudar/odk-sms-bridge >>> >>> >>> >>> I found it easy to work with. I believe I was building per commit, >>> >>> not >>> >>> nightly. It isn't a complicated project, however, and I don't know >>> >>> what >>> >>> it's like setting it up for publishing the nightly builds to a >>> >>> location. >>> >>> >>> >>> I have no experience building signed APKs automatically, so I can't >>> >>> speak >>> >>> to Chris's points about key locations or automatic signing. >>> >>> >>> >>> On Tue, Aug 23, 2016 at 5:37 AM, Christopher Robert wrote: >>> >>>> >>> >>>> Hi Yaw, >>> >>>> >>> >>>> We automate builds with Jenkins on AWS EC2. However, we have always >>> >>>> built our Android apk separately for a couple of reasons: >>> >>>> >>> >>>> We wanted to more tightly control the build environment, including >>> >>>> the >>> >>>> version of Java. >>> >>>> We wanted to guard the key we used to sign the apk closely. >>> >>>> And we ran into trouble with the Android SDK on EC2 (something about >>> >>>> x64 >>> >>>> EC2 environments). >>> >>>> >>> >>>> For 3, there are blog posts like this one, AWS seems to have >>> >>>> embraced >>> >>>> Jenkins, and with their mobile SDK AWS is clearly trying to >>> >>>> accommodate >>> >>>> mobile developers. So I suspect that if we went back to try it >>> >>>> again, >>> >>>> everything would be fine. >>> >>>> >>> >>>> As for 1 and 2, I think that those are less of a concern now. Back >>> >>>> in >>> >>>> 2013 we were a bit less comfortable with our EC2/Linux skills and so >>> >>>> we >>> >>>> preferred building with Maven on OSX. But now I think that we could >>> >>>> have a >>> >>>> well-controlled environment on which we wouldn't mind housing our >>> >>>> private >>> >>>> key. >>> >>>> >>> >>>> So, I'd recommend Jenkins on EC2 -- though I will say that it's not >>> >>>> uncommon for Jenkins to get OOM errors and need to be restarted. We >>> >>>> keep >>> >>>> bumping up the memory on our dev server, but nothing seems to be >>> >>>> quite what >>> >>>> Jenkins wants. (I think that it wants a large memory swap file, but >>> >>>> we don't >>> >>>> have a local drive on that machine and so don't have a memory swap >>> >>>> configured.) >>> >>>> >>> >>>> Best, >>> >>>> >>> >>>> Chris >>> >>>> >>> >>>> On Tue, Aug 23, 2016 at 8:21 AM Yaw Anokwa wrote: >>> >>>>> >>> >>>>> Hi all, >>> >>>>> >>> >>>>> I'd like to get automated nightly builds for ODK Collect and I'd >>> >>>>> love >>> >>>>> to hear from folks who've used continuous integration and testing >>> >>>>> on >>> >>>>> Android apps. >>> >>>>> >>> >>>>> I'm guessing the folks at Dimagi, Kobo, SurveyCTO, Ona, and ELMO >>> >>>>> all >>> >>>>> have some experience here. What platform did you use? Would you >>> >>>>> recommend it? >>> >>>>> >>> >>>>> Thanks, >>> >>>>> >>> >>>>> Yaw >>> >>>>> >>> >>>>> -- >>> >>>>> You received this message because you are subscribed to the Google >>> >>>>> Groups "ODK Developers" group. >>> >>>>> To unsubscribe from this group and stop receiving emails from it, >>> >>>>> send >>> >>>>> an email to opendatakit-developers+unsubscribe@googlegroups.com. >>> >>>>> For more options, visit https://groups.google.com/d/optout. >>> >>>> >>> >>>> -- >>> >>>> You received this message because you are subscribed to the Google >>> >>>> Groups "ODK Developers" group. >>> >>>> To unsubscribe from this group and stop receiving emails from it, >>> >>>> send >>> >>>> an email to opendatakit-developers+unsubscribe@googlegroups.com. >>> >>>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> >>> >>> >>> -- >>> >>> You received this message because you are subscribed to the Google >>> >>> Groups >>> >>> "ODK Developers" group. >>> >>> To unsubscribe from this group and stop receiving emails from it, >>> >>> send an >>> >>> email to opendatakit-developers+unsubscribe@googlegroups.com. >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >>> >> >>> >> -- >>> >> You received this message because you are subscribed to the Google >>> >> Groups >>> >> "ODK Developers" group. >>> >> To unsubscribe from this group and stop receiving emails from it, send >>> >> an >>> >> email to opendatakit-developers+unsubscribe@googlegroups.com. >>> >> For more options, visit https://groups.google.com/d/optout. >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> > Groups >>> > "ODK Developers" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> > an >>> > email to opendatakit-developers+unsubscribe@googlegroups.com. >>> > For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "ODK Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to opendatakit-developers+unsubscribe@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "ODK Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to opendatakit-developers+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout.

(Brent Atkinson) #10

Hi Yaw,

Unfortunately, I can not do this with collect since I am not part of the
github organization.

However, I tried it with another android project. It did a good job of
inferring the basic setup, but not enough to successfully build the
project. It failed due to the android setup not being the version expected
for the project. Looking into a resolution, it appears Circle is very
similar to TravisCI. You have to specify additional specifications and/or
commands in a special yaml file in the repository. Also, the host is
configured fresh from a base image every time. Android SDK commands need to
be run to install build tools or API before the build commands, which
increases the build times considerably compared to a base image customized
to the application. There are ways to ask CircleCI to cache certain
directories, which can limit the effects of this.

I think this would work, but I don't see anything specific to CircleCI that
makes it better than others for android development. I guess the big items
would be:

  • Android SDK and NDK are pre-installed (though may need to use commands
    to install other versions anyway)
  • A working emulator configuration is pre-installed through AVD

That's about it. If the build config doesn't match, you still need to
re-configure the host. Deployment appears to be through normal gradle
plugins, which would work for any build system.

The basic instructions for building android apps:
https://circleci.com/docs/android/
A description of how caching works:
https://circleci.com/docs/how-cache-works/

Hope this helps,

Brent

ยทยทยท On Fri, Aug 26, 2016 at 7:46 AM, Yaw Anokwa wrote:

Thanks for looking into CircleCI, Brent. My gut says that we should
try it first, if that ends up sucking, we can fallback switch to
Jenkins, warts and all. Do you have the cycles to give it a try on the
Collect repo?

Yaw

On Thu, Aug 25, 2016 at 2:37 PM, Brent Atkinson brent.atkinson@gmail.com wrote:

Sorry for the noise, but reading more on CircleCI, they claim that they
allow you to do whatever you want on their environments. It probably
still
means you're stuck with their starting environments, but it seems you at
least have full control over them.

Brent

On Thu, Aug 25, 2016 at 10:28 AM, Brent Atkinson < brent.atkinson@gmail.com> wrote:

Hi,

I have used Jenkins and Travis. I haven't used CircleCI, but it seems
extremely similar in spirit to Travis (connect your GitHub project and
go,

add YAML for customization).

In my experience, the biggest difference between Jenkins and these other
tools is that it is extremely flexible in terms of deployment. You can
setup

a single master on your machine, a massive master/slave setup in the
cloud,

or use as-a-service with something like CloudBees. My experience with
CIaaS

is that it's a perfect free option for projects that fit well within the
templates, but once you start needing more exotic configurations not
being

able to fully control the environment makes them less attractive.

Brent

On Wednesday, August 24, 2016 at 4:01:54 AM UTC-4, Yaw Anokwa wrote:

This is great info. Looks like Jenkins is what most are using. My
light reading is that their Android integration isn't amazing.

Has anyone tried CircleCI? It visually looks better, has reportedly
better Android support, and is free for OSS.

On Tue, Aug 23, 2016 at 10:53 PM, Matt Berg mlb...@gmail.com wrote:

We use Jenkins and Drone. Jenkins I believe offers a free service
for

OS
projects if you are ok with waiting for your builds in a queue.

Matt

On Aug 23, 2016 1:34 PM, "Jeffrey Beorse" jbe...@cs.washington.edu wrote:

Hi Yaw,

I'm not sure how familiar you are with what we're doing in ODK 2.0,
but
we're using Jenkins to decent success. I'd echo Chris's endorsement
of

Jenkins on EC2.

Jenkins is pretty powerful and gives you a lot of control over the
details
of your build. There are vast amounts of plugins, including
integration with
Github, Gradle, Android Emulators, JaCoCo, etc. We're running custom
scripts
to handle copying file dependencies, automating multi-emulator test
suites,
controlling slave systems for UI tests, publishing binaries through
Artifactory, graphing code coverage summaries, and more. We're
running

automatic builds on each push to the development or demo branches,
including
building signed APKs. We still build our master branch release
binaries by
hand because we like to do some hand testing before the real
release,

but we
could easily build them with Jenkins too.

Its not all perfect, of course. As Chris implied, Jenkins can be
pretty
finicky. With each version bump we seem to have to fix our github
integration. Documentation can be spotty depending on the plugin.
Emulators
misbehave, though this is probably more Google's fault.

I don't have any experience with Travis, so I can't compare the two
systems. All I can say is we've had an overall positive experience
with
Jenkins.

Regards,
Jeff

On Tue, Aug 23, 2016 at 8:50 AM, Sam Sudar suda...@gmail.com wrote:

I've used Travis github integration in the past for a small
project:

https://github.com/srsudar/odk-sms-bridge

You can see example build output here:

https://travis-ci.org/srsudar/odk-sms-bridge

I found it easy to work with. I believe I was building per commit,
not
nightly. It isn't a complicated project, however, and I don't know
what
it's like setting it up for publishing the nightly builds to a
location.

I have no experience building signed APKs automatically, so I can't
speak
to Chris's points about key locations or automatic signing.

On Tue, Aug 23, 2016 at 5:37 AM, Christopher Robert cro...@surveycto.com wrote:

Hi Yaw,

We automate builds with Jenkins on AWS EC2. However, we have
always

built our Android apk separately for a couple of reasons:

We wanted to more tightly control the build environment, including
the
version of Java.
We wanted to guard the key we used to sign the apk closely.
And we ran into trouble with the Android SDK on EC2 (something
about

x64
EC2 environments).

For 3, there are blog posts like this one, AWS seems to have
embraced
Jenkins, and with their mobile SDK AWS is clearly trying to
accommodate
mobile developers. So I suspect that if we went back to try it
again,
everything would be fine.

As for 1 and 2, I think that those are less of a concern now. Back
in
2013 we were a bit less comfortable with our EC2/Linux skills and
so

we
preferred building with Maven on OSX. But now I think that we
could

have a
well-controlled environment on which we wouldn't mind housing our
private
key.

So, I'd recommend Jenkins on EC2 -- though I will say that it's
not

uncommon for Jenkins to get OOM errors and need to be restarted.
We

keep
bumping up the memory on our dev server, but nothing seems to be
quite what
Jenkins wants. (I think that it wants a large memory swap file,
but

we don't
have a local drive on that machine and so don't have a memory swap
configured.)

Best,

Chris

On Tue, Aug 23, 2016 at 8:21 AM Yaw Anokwa yan...@nafundi.com wrote:

Hi all,

I'd like to get automated nightly builds for ODK Collect and I'd
love
to hear from folks who've used continuous integration and testing
on
Android apps.

I'm guessing the folks at Dimagi, Kobo, SurveyCTO, Ona, and ELMO
all
have some experience here. What platform did you use? Would you
recommend it?

Thanks,

Yaw

--
You received this message because you are subscribed to the
Google

Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(Carl Hartung) #11

Hey Brent,
After your trial with CircleCI compared to your experience in Jenkins and
Travis, do you find yourself having a preference for one? or think one
would work better for Collect?

It sounds like there's generally more experience amonst the community with
Jenkins, so it might be easier to use/modify/troubleshoot if we go that
route.
-Carl

ยทยทยท On Fri, Aug 26, 2016 at 7:40 AM, Brent Atkinson wrote:

Hi Yaw,

Unfortunately, I can not do this with collect since I am not part of the
github organization.

However, I tried it with another android project. It did a good job of
inferring the basic setup, but not enough to successfully build the
project. It failed due to the android setup not being the version expected
for the project. Looking into a resolution, it appears Circle is very
similar to TravisCI. You have to specify additional specifications and/or
commands in a special yaml file in the repository. Also, the host is
configured fresh from a base image every time. Android SDK commands need to
be run to install build tools or API before the build commands, which
increases the build times considerably compared to a base image customized
to the application. There are ways to ask CircleCI to cache certain
directories, which can limit the effects of this.

I think this would work, but I don't see anything specific to CircleCI
that makes it better than others for android development. I guess the big
items would be:

  • Android SDK and NDK are pre-installed (though may need to use
    commands to install other versions anyway)
  • A working emulator configuration is pre-installed through AVD

That's about it. If the build config doesn't match, you still need to
re-configure the host. Deployment appears to be through normal gradle
plugins, which would work for any build system.

The basic instructions for building android apps: https://circleci.com/
docs/android/
A description of how caching works: https://circleci.com/
docs/how-cache-works/

Hope this helps,

Brent

On Fri, Aug 26, 2016 at 7:46 AM, Yaw Anokwa yanokwa@nafundi.com wrote:

Thanks for looking into CircleCI, Brent. My gut says that we should
try it first, if that ends up sucking, we can fallback switch to
Jenkins, warts and all. Do you have the cycles to give it a try on the
Collect repo?

Yaw

On Thu, Aug 25, 2016 at 2:37 PM, Brent Atkinson brent.atkinson@gmail.com wrote:

Sorry for the noise, but reading more on CircleCI, they claim that they
allow you to do whatever you want on their environments. It probably
still
means you're stuck with their starting environments, but it seems you at
least have full control over them.

Brent

On Thu, Aug 25, 2016 at 10:28 AM, Brent Atkinson < brent.atkinson@gmail.com> wrote:

Hi,

I have used Jenkins and Travis. I haven't used CircleCI, but it seems
extremely similar in spirit to Travis (connect your GitHub project and
go,

add YAML for customization).

In my experience, the biggest difference between Jenkins and these
other

tools is that it is extremely flexible in terms of deployment. You can
setup

a single master on your machine, a massive master/slave setup in the
cloud,

or use as-a-service with something like CloudBees. My experience with
CIaaS

is that it's a perfect free option for projects that fit well within
the

templates, but once you start needing more exotic configurations not
being

able to fully control the environment makes them less attractive.

Brent

On Wednesday, August 24, 2016 at 4:01:54 AM UTC-4, Yaw Anokwa wrote:

This is great info. Looks like Jenkins is what most are using. My
light reading is that their Android integration isn't amazing.

Has anyone tried CircleCI? It visually looks better, has reportedly
better Android support, and is free for OSS.

On Tue, Aug 23, 2016 at 10:53 PM, Matt Berg mlb...@gmail.com wrote:

We use Jenkins and Drone. Jenkins I believe offers a free service
for

OS
projects if you are ok with waiting for your builds in a queue.

Matt

On Aug 23, 2016 1:34 PM, "Jeffrey Beorse" <jbe...@cs.washington.edu wrote:

Hi Yaw,

I'm not sure how familiar you are with what we're doing in ODK 2.0,
but
we're using Jenkins to decent success. I'd echo Chris's
endorsement of

Jenkins on EC2.

Jenkins is pretty powerful and gives you a lot of control over the
details
of your build. There are vast amounts of plugins, including
integration with
Github, Gradle, Android Emulators, JaCoCo, etc. We're running
custom

scripts
to handle copying file dependencies, automating multi-emulator test
suites,
controlling slave systems for UI tests, publishing binaries through
Artifactory, graphing code coverage summaries, and more. We're
running

automatic builds on each push to the development or demo branches,
including
building signed APKs. We still build our master branch release
binaries by
hand because we like to do some hand testing before the real
release,

but we
could easily build them with Jenkins too.

Its not all perfect, of course. As Chris implied, Jenkins can be
pretty
finicky. With each version bump we seem to have to fix our github
integration. Documentation can be spotty depending on the plugin.
Emulators
misbehave, though this is probably more Google's fault.

I don't have any experience with Travis, so I can't compare the two
systems. All I can say is we've had an overall positive experience
with
Jenkins.

Regards,
Jeff

On Tue, Aug 23, 2016 at 8:50 AM, Sam Sudar suda...@gmail.com wrote:

I've used Travis github integration in the past for a small
project:

https://github.com/srsudar/odk-sms-bridge

You can see example build output here:

https://travis-ci.org/srsudar/odk-sms-bridge

I found it easy to work with. I believe I was building per commit,
not
nightly. It isn't a complicated project, however, and I don't
know

what
it's like setting it up for publishing the nightly builds to a
location.

I have no experience building signed APKs automatically, so I
can't

speak
to Chris's points about key locations or automatic signing.

On Tue, Aug 23, 2016 at 5:37 AM, Christopher Robert cro...@surveycto.com wrote:

Hi Yaw,

We automate builds with Jenkins on AWS EC2. However, we have
always

built our Android apk separately for a couple of reasons:

We wanted to more tightly control the build environment,
including

the
version of Java.
We wanted to guard the key we used to sign the apk closely.
And we ran into trouble with the Android SDK on EC2 (something
about

x64
EC2 environments).

For 3, there are blog posts like this one, AWS seems to have
embraced
Jenkins, and with their mobile SDK AWS is clearly trying to
accommodate
mobile developers. So I suspect that if we went back to try it
again,
everything would be fine.

As for 1 and 2, I think that those are less of a concern now.
Back

in
2013 we were a bit less comfortable with our EC2/Linux skills
and so

we
preferred building with Maven on OSX. But now I think that we
could

have a
well-controlled environment on which we wouldn't mind housing our
private
key.

So, I'd recommend Jenkins on EC2 -- though I will say that it's
not

uncommon for Jenkins to get OOM errors and need to be restarted.
We

keep
bumping up the memory on our dev server, but nothing seems to be
quite what
Jenkins wants. (I think that it wants a large memory swap file,
but

we don't
have a local drive on that machine and so don't have a memory
swap

configured.)

Best,

Chris

On Tue, Aug 23, 2016 at 8:21 AM Yaw Anokwa yan...@nafundi.com wrote:

Hi all,

I'd like to get automated nightly builds for ODK Collect and I'd
love
to hear from folks who've used continuous integration and
testing

on
Android apps.

I'm guessing the folks at Dimagi, Kobo, SurveyCTO, Ona, and ELMO
all
have some experience here. What platform did you use? Would you
recommend it?

Thanks,

Yaw

--
You received this message because you are subscribed to the
Google

Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it,

send
an email to opendatakit-developers+unsubscribe@googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google

Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(Brent Atkinson) #12

Hi Carl,

Apologies for the delay responding. I don't know enough to say with
confidence which I would prefer at this point. I believe almost all of
these could work since most CI software systems are doing very similar
things. My sense is that it will boil down to whether we need/want full
control and have the resources to commit or whether we need/want to use a
freely available service and don't need as much control.

My inclination would be to use the CI-as-a-service tools unless it just
won't work for what we want it for. It's less of a commitment from a
time/money perspective unless it just can't work for what we're looking to
do.

The types of questions I would want to answer to have confidence in a
recommendation for ODK:

  • Do we have resources to build and maintain and monitor a build farm
    over time?
    • No: I would favor CI-as-a-service like Travis/Circle - no host
      provisioning or maintenance, minimal or no cost
    • Yes: Full control over all aspects of setup using a free-as-in-beer
      server like Jenkins is more attractive
  • Are there parts of ODK that can not be made publicly available?
    • No: CI-as-a-service like Travis/Circle are still an option
    • Yes: Private build farm might be necessary, though could still be
      possible to use CI-as-a-service depending on the specifics (may require
      more $ or configuration to make it work)
  • What level of maturity are we looking to achieve with the CI setup?
    • Basic (basic builds on commit, test running/reporting):
      CI-as-a-service is often a better option due to low/no cost and
      and no host
      maintenance
    • Intermediate (grid builds, additional analytics and trending):
      Depending on specifics could favor CI-as-a-service for turn key
      simplicity,
      or private setup for ease due to having full control over
      configuration and
      deployment
    • Advanced (complicated build pipelines, custom plugins, exotic build
      environments): Usually favor the private setup due to controlling all
      aspects of setup, however, pay options for the other tools are available
      and may be as good or better as freely available tools like Jenkins
  • Do we need to handle secrets like API keys or signing certificates as
    part of the build process (or deployment if we're doing full deployment
    pipeline)?
    • Yes: CI-as-a-service like Travis/Circle allow for encrypting
      environment variables and files so you can check them into projects and
      still keep their contents private. The simplicity of
      CI-as-a-service starts
      to fade a bit here. It may be easier/safer to run only on private servers
      depending on pain involved or level of paranoia.
    • No: CI-as-a-service can be far faster if the setup is directly
      supported. This relates to what I was testing before, and unfortunately,
      the fact that the android API 19 wasn't installed already, meant I have
      more work to do to make CI-as-a-service work. This doesn't
      necessarily make
      it worse than a private setup though, since you have to
      configure/provision
      everything in that case.

I'm sure there are other important details I am missing, but this should
give you an idea of the types of things to consider and have clarity on. At
this point, I still think it is worth seeing how far we can go with a
CI-as-a-service setup unless we can identify a deal breaker and/or
self-hosting on a longer time scale isn't feasible for the project.

If you all think it is worth while, I am willing to continue attempting to
setup Collect to build on both Travis and Circle. It might be possible for
me to fork Collect so I don't need special permissions and then submit the
configs back as pull requests. Then you all could review them, and choose
which to integrate, if any?

Brent

ยทยทยท On Fri, Aug 26, 2016 at 7:33 PM, Carl Hartung wrote:

Hey Brent,
After your trial with CircleCI compared to your experience in Jenkins and
Travis, do you find yourself having a preference for one? or think one
would work better for Collect?

It sounds like there's generally more experience amonst the community with
Jenkins, so it might be easier to use/modify/troubleshoot if we go that
route.
-Carl

On Fri, Aug 26, 2016 at 7:40 AM, Brent Atkinson brent.atkinson@gmail.com wrote:

Hi Yaw,

Unfortunately, I can not do this with collect since I am not part of the
github organization.

However, I tried it with another android project. It did a good job of
inferring the basic setup, but not enough to successfully build the
project. It failed due to the android setup not being the version expected
for the project. Looking into a resolution, it appears Circle is very
similar to TravisCI. You have to specify additional specifications and/or
commands in a special yaml file in the repository. Also, the host is
configured fresh from a base image every time. Android SDK commands need to
be run to install build tools or API before the build commands, which
increases the build times considerably compared to a base image customized
to the application. There are ways to ask CircleCI to cache certain
directories, which can limit the effects of this.

I think this would work, but I don't see anything specific to CircleCI
that makes it better than others for android development. I guess the big
items would be:

  • Android SDK and NDK are pre-installed (though may need to use
    commands to install other versions anyway)
  • A working emulator configuration is pre-installed through AVD

That's about it. If the build config doesn't match, you still need to
re-configure the host. Deployment appears to be through normal gradle
plugins, which would work for any build system.

The basic instructions for building android apps:
https://circleci.com/docs/android/
A description of how caching works: https://circleci.com/do
cs/how-cache-works/

Hope this helps,

Brent

On Fri, Aug 26, 2016 at 7:46 AM, Yaw Anokwa yanokwa@nafundi.com wrote:

Thanks for looking into CircleCI, Brent. My gut says that we should
try it first, if that ends up sucking, we can fallback switch to
Jenkins, warts and all. Do you have the cycles to give it a try on the
Collect repo?

Yaw

On Thu, Aug 25, 2016 at 2:37 PM, Brent Atkinson brent.atkinson@gmail.com wrote:

Sorry for the noise, but reading more on CircleCI, they claim that they
allow you to do whatever you want on their environments. It probably
still
means you're stuck with their starting environments, but it seems you
at
least have full control over them.

Brent

On Thu, Aug 25, 2016 at 10:28 AM, Brent Atkinson < brent.atkinson@gmail.com> wrote:

Hi,

I have used Jenkins and Travis. I haven't used CircleCI, but it seems
extremely similar in spirit to Travis (connect your GitHub project
and go,

add YAML for customization).

In my experience, the biggest difference between Jenkins and these
other

tools is that it is extremely flexible in terms of deployment. You
can setup

a single master on your machine, a massive master/slave setup in the
cloud,

or use as-a-service with something like CloudBees. My experience with
CIaaS

is that it's a perfect free option for projects that fit well within
the

templates, but once you start needing more exotic configurations not
being

able to fully control the environment makes them less attractive.

Brent

On Wednesday, August 24, 2016 at 4:01:54 AM UTC-4, Yaw Anokwa wrote:

This is great info. Looks like Jenkins is what most are using. My
light reading is that their Android integration isn't amazing.

Has anyone tried CircleCI? It visually looks better, has reportedly
better Android support, and is free for OSS.

On Tue, Aug 23, 2016 at 10:53 PM, Matt Berg mlb...@gmail.com wrote:

We use Jenkins and Drone. Jenkins I believe offers a free service
for

OS
projects if you are ok with waiting for your builds in a queue.

Matt

On Aug 23, 2016 1:34 PM, "Jeffrey Beorse" < jbe...@cs.washington.edu> wrote:

Hi Yaw,

I'm not sure how familiar you are with what we're doing in ODK
2.0,

but
we're using Jenkins to decent success. I'd echo Chris's
endorsement of

Jenkins on EC2.

Jenkins is pretty powerful and gives you a lot of control over the
details
of your build. There are vast amounts of plugins, including
integration with
Github, Gradle, Android Emulators, JaCoCo, etc. We're running
custom

scripts
to handle copying file dependencies, automating multi-emulator
test

suites,
controlling slave systems for UI tests, publishing binaries
through

Artifactory, graphing code coverage summaries, and more. We're
running

automatic builds on each push to the development or demo branches,
including
building signed APKs. We still build our master branch release
binaries by
hand because we like to do some hand testing before the real
release,

but we
could easily build them with Jenkins too.

Its not all perfect, of course. As Chris implied, Jenkins can be
pretty
finicky. With each version bump we seem to have to fix our github
integration. Documentation can be spotty depending on the plugin.
Emulators
misbehave, though this is probably more Google's fault.

I don't have any experience with Travis, so I can't compare the
two

systems. All I can say is we've had an overall positive experience
with
Jenkins.

Regards,
Jeff

On Tue, Aug 23, 2016 at 8:50 AM, Sam Sudar suda...@gmail.com wrote:

I've used Travis github integration in the past for a small
project:

https://github.com/srsudar/odk-sms-bridge

You can see example build output here:

https://travis-ci.org/srsudar/odk-sms-bridge

I found it easy to work with. I believe I was building per
commit,

not
nightly. It isn't a complicated project, however, and I don't
know

what
it's like setting it up for publishing the nightly builds to a
location.

I have no experience building signed APKs automatically, so I
can't

speak
to Chris's points about key locations or automatic signing.

On Tue, Aug 23, 2016 at 5:37 AM, Christopher Robert cro...@surveycto.com wrote:

Hi Yaw,

We automate builds with Jenkins on AWS EC2. However, we have
always

built our Android apk separately for a couple of reasons:

We wanted to more tightly control the build environment,
including

the
version of Java.
We wanted to guard the key we used to sign the apk closely.
And we ran into trouble with the Android SDK on EC2 (something
about

x64
EC2 environments).

For 3, there are blog posts like this one, AWS seems to have
embraced
Jenkins, and with their mobile SDK AWS is clearly trying to
accommodate
mobile developers. So I suspect that if we went back to try it
again,
everything would be fine.

As for 1 and 2, I think that those are less of a concern now.
Back

in
2013 we were a bit less comfortable with our EC2/Linux skills
and so

we
preferred building with Maven on OSX. But now I think that we
could

have a
well-controlled environment on which we wouldn't mind housing
our

private
key.

So, I'd recommend Jenkins on EC2 -- though I will say that it's
not

uncommon for Jenkins to get OOM errors and need to be
restarted. We

keep
bumping up the memory on our dev server, but nothing seems to be
quite what
Jenkins wants. (I think that it wants a large memory swap file,
but

we don't
have a local drive on that machine and so don't have a memory
swap

configured.)

Best,

Chris

On Tue, Aug 23, 2016 at 8:21 AM Yaw Anokwa yan...@nafundi.com wrote:

Hi all,

I'd like to get automated nightly builds for ODK Collect and
I'd

love
to hear from folks who've used continuous integration and
testing

on
Android apps.

I'm guessing the folks at Dimagi, Kobo, SurveyCTO, Ona, and
ELMO

all
have some experience here. What platform did you use? Would you
recommend it?

Thanks,

Yaw

--
You received this message because you are subscribed to the
Google

Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it,

send
an email to opendatakit-developers+unsubsc
ribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google

Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it,

send
an email to opendatakit-developers+unsubscribe@googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(Daniel Kayiwa) #13

I have seen a few projects realising that they made a mistake trying to
manage their own infrastructure servers, and hence having to go through the
pain of switching.
So basing on this experience, even if the resources are available, i would
vote for starting simple, with CI-as-a-service like Travis or Circle, etc.
Then switch, only if it turns out not to meet the actual needs.

ยทยทยท On Mon, Aug 29, 2016 at 6:59 PM, Brent Atkinson wrote:

Hi Carl,

Apologies for the delay responding. I don't know enough to say with
confidence which I would prefer at this point. I believe almost all of
these could work since most CI software systems are doing very similar
things. My sense is that it will boil down to whether we need/want full
control and have the resources to commit or whether we need/want to use a
freely available service and don't need as much control.

My inclination would be to use the CI-as-a-service tools unless it just
won't work for what we want it for. It's less of a commitment from a
time/money perspective unless it just can't work for what we're looking to
do.

The types of questions I would want to answer to have confidence in a
recommendation for ODK:

  • Do we have resources to build and maintain and monitor a build farm
    over time?
    • No: I would favor CI-as-a-service like Travis/Circle - no host
      provisioning or maintenance, minimal or no cost
    • Yes: Full control over all aspects of setup using a
      free-as-in-beer server like Jenkins is more attractive
  • Are there parts of ODK that can not be made publicly available?
    • No: CI-as-a-service like Travis/Circle are still an option
    • Yes: Private build farm might be necessary, though could still be
      possible to use CI-as-a-service depending on the specifics (may require
      more $ or configuration to make it work)
  • What level of maturity are we looking to achieve with the CI setup?
    • Basic (basic builds on commit, test running/reporting):
      CI-as-a-service is often a better option due to low/no cost and and no host
      maintenance
    • Intermediate (grid builds, additional analytics and trending):
      Depending on specifics could favor CI-as-a-service for turn key simplicity,
      or private setup for ease due to having full control over configuration and
      deployment
    • Advanced (complicated build pipelines, custom plugins, exotic
      build environments): Usually favor the private setup due to controlling all
      aspects of setup, however, pay options for the other tools are available
      and may be as good or better as freely available tools like Jenkins
  • Do we need to handle secrets like API keys or signing certificates
    as part of the build process (or deployment if we're doing full deployment
    pipeline)?
    • Yes: CI-as-a-service like Travis/Circle allow for encrypting
      environment variables and files so you can check them into projects and
      still keep their contents private. The simplicity of CI-as-a-service starts
      to fade a bit here. It may be easier/safer to run only on private servers
      depending on pain involved or level of paranoia.
    • No: CI-as-a-service can be far faster if the setup is directly
      supported. This relates to what I was testing before, and unfortunately,
      the fact that the android API 19 wasn't installed already, meant I have
      more work to do to make CI-as-a-service work. This doesn't necessarily make
      it worse than a private setup though, since you have to configure/provision
      everything in that case.

I'm sure there are other important details I am missing, but this should
give you an idea of the types of things to consider and have clarity on. At
this point, I still think it is worth seeing how far we can go with a
CI-as-a-service setup unless we can identify a deal breaker and/or
self-hosting on a longer time scale isn't feasible for the project.

If you all think it is worth while, I am willing to continue attempting to
setup Collect to build on both Travis and Circle. It might be possible for
me to fork Collect so I don't need special permissions and then submit the
configs back as pull requests. Then you all could review them, and choose
which to integrate, if any?

Brent

On Fri, Aug 26, 2016 at 7:33 PM, Carl Hartung chartung@nafundi.com wrote:

Hey Brent,
After your trial with CircleCI compared to your experience in Jenkins and
Travis, do you find yourself having a preference for one? or think one
would work better for Collect?

It sounds like there's generally more experience amonst the community
with Jenkins, so it might be easier to use/modify/troubleshoot if we go
that route.
-Carl

On Fri, Aug 26, 2016 at 7:40 AM, Brent Atkinson <brent.atkinson@gmail.com wrote:

Hi Yaw,

Unfortunately, I can not do this with collect since I am not part of the
github organization.

However, I tried it with another android project. It did a good job of
inferring the basic setup, but not enough to successfully build the
project. It failed due to the android setup not being the version expected
for the project. Looking into a resolution, it appears Circle is very
similar to TravisCI. You have to specify additional specifications and/or
commands in a special yaml file in the repository. Also, the host is
configured fresh from a base image every time. Android SDK commands need to
be run to install build tools or API before the build commands, which
increases the build times considerably compared to a base image customized
to the application. There are ways to ask CircleCI to cache certain
directories, which can limit the effects of this.

I think this would work, but I don't see anything specific to CircleCI
that makes it better than others for android development. I guess the big
items would be:

  • Android SDK and NDK are pre-installed (though may need to use
    commands to install other versions anyway)
  • A working emulator configuration is pre-installed through AVD

That's about it. If the build config doesn't match, you still need to
re-configure the host. Deployment appears to be through normal gradle
plugins, which would work for any build system.

The basic instructions for building android apps:
https://circleci.com/docs/android/
A description of how caching works: https://circleci.com/do
cs/how-cache-works/

Hope this helps,

Brent

On Fri, Aug 26, 2016 at 7:46 AM, Yaw Anokwa yanokwa@nafundi.com wrote:

Thanks for looking into CircleCI, Brent. My gut says that we should
try it first, if that ends up sucking, we can fallback switch to
Jenkins, warts and all. Do you have the cycles to give it a try on the
Collect repo?

Yaw

On Thu, Aug 25, 2016 at 2:37 PM, Brent Atkinson brent.atkinson@gmail.com wrote:

Sorry for the noise, but reading more on CircleCI, they claim that
they
allow you to do whatever you want on their environments. It probably
still
means you're stuck with their starting environments, but it seems you
at
least have full control over them.

Brent

On Thu, Aug 25, 2016 at 10:28 AM, Brent Atkinson < brent.atkinson@gmail.com> wrote:

Hi,

I have used Jenkins and Travis. I haven't used CircleCI, but it seems
extremely similar in spirit to Travis (connect your GitHub project
and go,

add YAML for customization).

In my experience, the biggest difference between Jenkins and these
other

tools is that it is extremely flexible in terms of deployment. You
can setup

a single master on your machine, a massive master/slave setup in the
cloud,

or use as-a-service with something like CloudBees. My experience
with CIaaS

is that it's a perfect free option for projects that fit well within
the

templates, but once you start needing more exotic configurations not
being

able to fully control the environment makes them less attractive.

Brent

On Wednesday, August 24, 2016 at 4:01:54 AM UTC-4, Yaw Anokwa wrote:

This is great info. Looks like Jenkins is what most are using. My
light reading is that their Android integration isn't amazing.

Has anyone tried CircleCI? It visually looks better, has reportedly
better Android support, and is free for OSS.

On Tue, Aug 23, 2016 at 10:53 PM, Matt Berg mlb...@gmail.com wrote:

We use Jenkins and Drone. Jenkins I believe offers a free
service for

OS
projects if you are ok with waiting for your builds in a queue.

Matt

On Aug 23, 2016 1:34 PM, "Jeffrey Beorse" < jbe...@cs.washington.edu> wrote:

Hi Yaw,

I'm not sure how familiar you are with what we're doing in ODK
2.0,

but
we're using Jenkins to decent success. I'd echo Chris's
endorsement of

Jenkins on EC2.

Jenkins is pretty powerful and gives you a lot of control over
the

details
of your build. There are vast amounts of plugins, including
integration with
Github, Gradle, Android Emulators, JaCoCo, etc. We're running
custom

scripts
to handle copying file dependencies, automating multi-emulator
test

suites,
controlling slave systems for UI tests, publishing binaries
through

Artifactory, graphing code coverage summaries, and more. We're
running

automatic builds on each push to the development or demo
branches,

including
building signed APKs. We still build our master branch release
binaries by
hand because we like to do some hand testing before the real
release,

but we
could easily build them with Jenkins too.

Its not all perfect, of course. As Chris implied, Jenkins can be
pretty
finicky. With each version bump we seem to have to fix our github
integration. Documentation can be spotty depending on the plugin.
Emulators
misbehave, though this is probably more Google's fault.

I don't have any experience with Travis, so I can't compare the
two

systems. All I can say is we've had an overall positive
experience

with
Jenkins.

Regards,
Jeff

On Tue, Aug 23, 2016 at 8:50 AM, Sam Sudar suda...@gmail.com wrote:

I've used Travis github integration in the past for a small
project:

https://github.com/srsudar/odk-sms-bridge

You can see example build output here:

https://travis-ci.org/srsudar/odk-sms-bridge

I found it easy to work with. I believe I was building per
commit,

not
nightly. It isn't a complicated project, however, and I don't
know

what
it's like setting it up for publishing the nightly builds to a
location.

I have no experience building signed APKs automatically, so I
can't

speak
to Chris's points about key locations or automatic signing.

On Tue, Aug 23, 2016 at 5:37 AM, Christopher Robert cro...@surveycto.com wrote:

Hi Yaw,

We automate builds with Jenkins on AWS EC2. However, we have
always

built our Android apk separately for a couple of reasons:

We wanted to more tightly control the build environment,
including

the
version of Java.
We wanted to guard the key we used to sign the apk closely.
And we ran into trouble with the Android SDK on EC2 (something
about

x64
EC2 environments).

For 3, there are blog posts like this one, AWS seems to have
embraced
Jenkins, and with their mobile SDK AWS is clearly trying to
accommodate
mobile developers. So I suspect that if we went back to try it
again,
everything would be fine.

As for 1 and 2, I think that those are less of a concern now.
Back

in
2013 we were a bit less comfortable with our EC2/Linux skills
and so

we
preferred building with Maven on OSX. But now I think that we
could

have a
well-controlled environment on which we wouldn't mind housing
our

private
key.

So, I'd recommend Jenkins on EC2 -- though I will say that
it's not

uncommon for Jenkins to get OOM errors and need to be
restarted. We

keep
bumping up the memory on our dev server, but nothing seems to
be

quite what
Jenkins wants. (I think that it wants a large memory swap
file, but

we don't
have a local drive on that machine and so don't have a memory
swap

configured.)

Best,

Chris

On Tue, Aug 23, 2016 at 8:21 AM Yaw Anokwa <yan...@nafundi.com wrote:

Hi all,

I'd like to get automated nightly builds for ODK Collect and
I'd

love
to hear from folks who've used continuous integration and
testing

on
Android apps.

I'm guessing the folks at Dimagi, Kobo, SurveyCTO, Ona, and
ELMO

all
have some experience here. What platform did you use? Would
you

recommend it?

Thanks,

Yaw

--
You received this message because you are subscribed to the
Google

Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it,

send
an email to opendatakit-developers+unsubsc
ribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google

Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it,

send
an email to opendatakit-developers+unsubsc
ribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it,

send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it, send

an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
If we keep uppermost in our minds the unkind and unjust acts of others, we
shall find it impossible to love them as Christ has loved us; but if our
thoughts dwell upon the wondrous love and pity of Christ for us, the same
spirit will flow out to others.


(Jeff Beorse) #14

Hi,

I made a couple personal forks of Collect and tried both Travis and Circle
CI just to see how they work, for fun. Below is my experience, but I only
spent an hour or two with them, so take everything with some salt. @Brent,
you should be able to fork Collect through the typical Github workflow and
everything should work. You can also just pull Collect from opendatakit's
github and push to an empty repo of your own.

Between the two cloud CI options, I found Circle CI's Android support to be
significantly smoother and easier to use. I believe Travis is still in
beta, so this may improve, but as it stands now Circle CI is nicer in my
opinion. With Circle CI I was able to sign up for an account, press go on
my Collect fork, and have it successfully build. I didn't even need to push
a yml file to my Github repo (though obviously we would need one for
anything more than a proof of concept). With Travis I spent a lot of time
fiddling with my yml and reading cryptic build failures when the equivalent
Gradle commands worked fine locally. I know Brent had issues with Circle CI
missing an Android API level, but you have to specify your API level in
Travis too, so that doesn't like a win to me. I am not aware of any
fundamental differences in their platforms, so more mature Android support
seems as good a reason as any to pick Circle CI.

Coming from a Jenkins background, they both felt very bare bones to me.
Right away I wondered how we might run emulator tests on multiple Android
OS versions (i.e. test on 4.3, 4.4, 5.0. 5.1, etc). What if we need
additional scripting or build environment control? Brent addresses these
types of things in his third bullet point above. But Collect's code base,
as it is today, doesn't have any tests and doesn't need a customized build
environment. So is it worth the effort to maintain a Jenkins server to have
these options in the future?

I agree with Brent's assessment above. Assuming we aren't afraid to switch
to Jenkins down the road, my vote would be to choose the tool that meets
our current needs with minimal effort and upgrade if a compelling reason
arises.

I'd definitely encourage more people to try forking Collect and
experimenting for themselves. It turned out to be dead simple. I'm
interested to hear all of your experiences. I'm also happy to contribute to
Brent's effort to make a comparable configuration if there is a list of
features desired from the server.

Regards,
Jeff

ยทยทยท On Mon, Aug 29, 2016 at 9:19 AM, Daniel Kayiwa wrote:

I have seen a few projects realising that they made a mistake trying to
manage their own infrastructure servers, and hence having to go through the
pain of switching.
So basing on this experience, even if the resources are available, i would
vote for starting simple, with CI-as-a-service like Travis or Circle, etc.
Then switch, only if it turns out not to meet the actual needs.

On Mon, Aug 29, 2016 at 6:59 PM, Brent Atkinson brent.atkinson@gmail.com wrote:

Hi Carl,

Apologies for the delay responding. I don't know enough to say with
confidence which I would prefer at this point. I believe almost all of
these could work since most CI software systems are doing very similar
things. My sense is that it will boil down to whether we need/want full
control and have the resources to commit or whether we need/want to use a
freely available service and don't need as much control.

My inclination would be to use the CI-as-a-service tools unless it just
won't work for what we want it for. It's less of a commitment from a
time/money perspective unless it just can't work for what we're looking to
do.

The types of questions I would want to answer to have confidence in a
recommendation for ODK:

  • Do we have resources to build and maintain and monitor a build farm
    over time?
    • No: I would favor CI-as-a-service like Travis/Circle - no host
      provisioning or maintenance, minimal or no cost
    • Yes: Full control over all aspects of setup using a
      free-as-in-beer server like Jenkins is more attractive
  • Are there parts of ODK that can not be made publicly available?
    • No: CI-as-a-service like Travis/Circle are still an option
    • Yes: Private build farm might be necessary, though could still
      be possible to use CI-as-a-service depending on the specifics (may require
      more $ or configuration to make it work)
  • What level of maturity are we looking to achieve with the CI setup?
    • Basic (basic builds on commit, test running/reporting):
      CI-as-a-service is often a better option due to low/no cost and and no host
      maintenance
    • Intermediate (grid builds, additional analytics and trending):
      Depending on specifics could favor CI-as-a-service for turn key simplicity,
      or private setup for ease due to having full control over configuration and
      deployment
    • Advanced (complicated build pipelines, custom plugins, exotic
      build environments): Usually favor the private setup due to controlling all
      aspects of setup, however, pay options for the other tools are available
      and may be as good or better as freely available tools like Jenkins
  • Do we need to handle secrets like API keys or signing certificates
    as part of the build process (or deployment if we're doing full deployment
    pipeline)?
    • Yes: CI-as-a-service like Travis/Circle allow for encrypting
      environment variables and files so you can check them into projects and
      still keep their contents private. The simplicity of CI-as-a-service starts
      to fade a bit here. It may be easier/safer to run only on private servers
      depending on pain involved or level of paranoia.
    • No: CI-as-a-service can be far faster if the setup is directly
      supported. This relates to what I was testing before, and unfortunately,
      the fact that the android API 19 wasn't installed already, meant I have
      more work to do to make CI-as-a-service work. This doesn't necessarily make
      it worse than a private setup though, since you have to configure/provision
      everything in that case.

I'm sure there are other important details I am missing, but this should
give you an idea of the types of things to consider and have clarity on. At
this point, I still think it is worth seeing how far we can go with a
CI-as-a-service setup unless we can identify a deal breaker and/or
self-hosting on a longer time scale isn't feasible for the project.

If you all think it is worth while, I am willing to continue attempting
to setup Collect to build on both Travis and Circle. It might be possible
for me to fork Collect so I don't need special permissions and then submit
the configs back as pull requests. Then you all could review them, and
choose which to integrate, if any?

Brent

On Fri, Aug 26, 2016 at 7:33 PM, Carl Hartung chartung@nafundi.com wrote:

Hey Brent,
After your trial with CircleCI compared to your experience in Jenkins
and Travis, do you find yourself having a preference for one? or think one
would work better for Collect?

It sounds like there's generally more experience amonst the community
with Jenkins, so it might be easier to use/modify/troubleshoot if we go
that route.
-Carl

On Fri, Aug 26, 2016 at 7:40 AM, Brent Atkinson < brent.atkinson@gmail.com> wrote:

Hi Yaw,

Unfortunately, I can not do this with collect since I am not part of
the github organization.

However, I tried it with another android project. It did a good job of
inferring the basic setup, but not enough to successfully build the
project. It failed due to the android setup not being the version expected
for the project. Looking into a resolution, it appears Circle is very
similar to TravisCI. You have to specify additional specifications and/or
commands in a special yaml file in the repository. Also, the host is
configured fresh from a base image every time. Android SDK commands need to
be run to install build tools or API before the build commands, which
increases the build times considerably compared to a base image customized
to the application. There are ways to ask CircleCI to cache certain
directories, which can limit the effects of this.

I think this would work, but I don't see anything specific to CircleCI
that makes it better than others for android development. I guess the big
items would be:

  • Android SDK and NDK are pre-installed (though may need to use
    commands to install other versions anyway)
  • A working emulator configuration is pre-installed through AVD

That's about it. If the build config doesn't match, you still need to
re-configure the host. Deployment appears to be through normal gradle
plugins, which would work for any build system.

The basic instructions for building android apps:
https://circleci.com/docs/android/
A description of how caching works: https://circleci.com/do
cs/how-cache-works/

Hope this helps,

Brent

On Fri, Aug 26, 2016 at 7:46 AM, Yaw Anokwa yanokwa@nafundi.com wrote:

Thanks for looking into CircleCI, Brent. My gut says that we should
try it first, if that ends up sucking, we can fallback switch to
Jenkins, warts and all. Do you have the cycles to give it a try on the
Collect repo?

Yaw

On Thu, Aug 25, 2016 at 2:37 PM, Brent Atkinson brent.atkinson@gmail.com wrote:

Sorry for the noise, but reading more on CircleCI, they claim that
they
allow you to do whatever you want on their environments. It probably
still
means you're stuck with their starting environments, but it seems
you at
least have full control over them.

Brent

On Thu, Aug 25, 2016 at 10:28 AM, Brent Atkinson < brent.atkinson@gmail.com> wrote:

Hi,

I have used Jenkins and Travis. I haven't used CircleCI, but it
seems

extremely similar in spirit to Travis (connect your GitHub project
and go,

add YAML for customization).

In my experience, the biggest difference between Jenkins and these
other

tools is that it is extremely flexible in terms of deployment. You
can setup

a single master on your machine, a massive master/slave setup in
the cloud,

or use as-a-service with something like CloudBees. My experience
with CIaaS

is that it's a perfect free option for projects that fit well
within the

templates, but once you start needing more exotic configurations
not being

able to fully control the environment makes them less attractive.

Brent

On Wednesday, August 24, 2016 at 4:01:54 AM UTC-4, Yaw Anokwa wrote:

This is great info. Looks like Jenkins is what most are using. My
light reading is that their Android integration isn't amazing.

Has anyone tried CircleCI? It visually looks better, has reportedly
better Android support, and is free for OSS.

On Tue, Aug 23, 2016 at 10:53 PM, Matt Berg mlb...@gmail.com wrote:

We use Jenkins and Drone. Jenkins I believe offers a free
service for

OS
projects if you are ok with waiting for your builds in a queue.

Matt

On Aug 23, 2016 1:34 PM, "Jeffrey Beorse" < jbe...@cs.washington.edu> wrote:

Hi Yaw,

I'm not sure how familiar you are with what we're doing in ODK
2.0,

but
we're using Jenkins to decent success. I'd echo Chris's
endorsement of

Jenkins on EC2.

Jenkins is pretty powerful and gives you a lot of control over
the

details
of your build. There are vast amounts of plugins, including
integration with
Github, Gradle, Android Emulators, JaCoCo, etc. We're running
custom

scripts
to handle copying file dependencies, automating multi-emulator
test

suites,
controlling slave systems for UI tests, publishing binaries
through

Artifactory, graphing code coverage summaries, and more. We're
running

automatic builds on each push to the development or demo
branches,

including
building signed APKs. We still build our master branch release
binaries by
hand because we like to do some hand testing before the real
release,

but we
could easily build them with Jenkins too.

Its not all perfect, of course. As Chris implied, Jenkins can be
pretty
finicky. With each version bump we seem to have to fix our
github

integration. Documentation can be spotty depending on the
plugin.

Emulators
misbehave, though this is probably more Google's fault.

I don't have any experience with Travis, so I can't compare the
two

systems. All I can say is we've had an overall positive
experience

with
Jenkins.

Regards,
Jeff

On Tue, Aug 23, 2016 at 8:50 AM, Sam Sudar suda...@gmail.com wrote:

I've used Travis github integration in the past for a small
project:

https://github.com/srsudar/odk-sms-bridge

You can see example build output here:

https://travis-ci.org/srsudar/odk-sms-bridge

I found it easy to work with. I believe I was building per
commit,

not
nightly. It isn't a complicated project, however, and I don't
know

what
it's like setting it up for publishing the nightly builds to a
location.

I have no experience building signed APKs automatically, so I
can't

speak
to Chris's points about key locations or automatic signing.

On Tue, Aug 23, 2016 at 5:37 AM, Christopher Robert cro...@surveycto.com wrote:

Hi Yaw,

We automate builds with Jenkins on AWS EC2. However, we have
always

built our Android apk separately for a couple of reasons:

We wanted to more tightly control the build environment,
including

the
version of Java.
We wanted to guard the key we used to sign the apk closely.
And we ran into trouble with the Android SDK on EC2
(something about

x64
EC2 environments).

For 3, there are blog posts like this one, AWS seems to have
embraced
Jenkins, and with their mobile SDK AWS is clearly trying to
accommodate
mobile developers. So I suspect that if we went back to try it
again,
everything would be fine.

As for 1 and 2, I think that those are less of a concern now.
Back

in
2013 we were a bit less comfortable with our EC2/Linux skills
and so

we
preferred building with Maven on OSX. But now I think that we
could

have a
well-controlled environment on which we wouldn't mind housing
our

private
key.

So, I'd recommend Jenkins on EC2 -- though I will say that
it's not

uncommon for Jenkins to get OOM errors and need to be
restarted. We

keep
bumping up the memory on our dev server, but nothing seems to
be

quite what
Jenkins wants. (I think that it wants a large memory swap
file, but

we don't
have a local drive on that machine and so don't have a memory
swap

configured.)

Best,

Chris

On Tue, Aug 23, 2016 at 8:21 AM Yaw Anokwa < yan...@nafundi.com> wrote:

Hi all,

I'd like to get automated nightly builds for ODK Collect and
I'd

love
to hear from folks who've used continuous integration and
testing

on
Android apps.

I'm guessing the folks at Dimagi, Kobo, SurveyCTO, Ona, and
ELMO

all
have some experience here. What platform did you use? Would
you

recommend it?

Thanks,

Yaw

--
You received this message because you are subscribed to the
Google

Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails
from it,

send
an email to opendatakit-developers+unsubsc
ribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google

Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it,

send
an email to opendatakit-developers+unsubsc
ribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it,

send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it, send

an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it, send

an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
If we keep uppermost in our minds the unkind and unjust acts of others, we
shall find it impossible to love them as Christ has loved us; but if our
thoughts dwell upon the wondrous love and pity of Christ for us, the same
spirit will flow out to others.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(Yaw Anokwa) #15

Hi Jeff,

Forgive my ignorance, but when I point CircleCI at my Collect fork, it
blows up with a NoClassDefFoundError:
org/gradle/cli/CommandLineParser. The full trace is at
http://dpaste.com/3E2GQQ0.

Did you do any configuration in CircleCI to get it to build or was it
really set it and forget?

Thanks,

Yaw

ยทยทยท -- Need ODK consultants? Nafundi provides form design, server setup, in-field training, and software development for ODK. Go to https://nafundi.com to get started.

On Fri, Sep 2, 2016 at 3:53 AM, Jeffrey Beorse jbeorse@cs.washington.edu wrote:

Hi,

I made a couple personal forks of Collect and tried both Travis and Circle
CI just to see how they work, for fun. Below is my experience, but I only
spent an hour or two with them, so take everything with some salt. @Brent,
you should be able to fork Collect through the typical Github workflow and
everything should work. You can also just pull Collect from opendatakit's
github and push to an empty repo of your own.

Between the two cloud CI options, I found Circle CI's Android support to be
significantly smoother and easier to use. I believe Travis is still in beta,
so this may improve, but as it stands now Circle CI is nicer in my opinion.
With Circle CI I was able to sign up for an account, press go on my Collect
fork, and have it successfully build. I didn't even need to push a yml file
to my Github repo (though obviously we would need one for anything more than
a proof of concept). With Travis I spent a lot of time fiddling with my yml
and reading cryptic build failures when the equivalent Gradle commands
worked fine locally. I know Brent had issues with Circle CI missing an
Android API level, but you have to specify your API level in Travis too, so
that doesn't like a win to me. I am not aware of any fundamental differences
in their platforms, so more mature Android support seems as good a reason as
any to pick Circle CI.

Coming from a Jenkins background, they both felt very bare bones to me.
Right away I wondered how we might run emulator tests on multiple Android OS
versions (i.e. test on 4.3, 4.4, 5.0. 5.1, etc). What if we need additional
scripting or build environment control? Brent addresses these types of
things in his third bullet point above. But Collect's code base, as it is
today, doesn't have any tests and doesn't need a customized build
environment. So is it worth the effort to maintain a Jenkins server to have
these options in the future?

I agree with Brent's assessment above. Assuming we aren't afraid to switch
to Jenkins down the road, my vote would be to choose the tool that meets our
current needs with minimal effort and upgrade if a compelling reason arises.

I'd definitely encourage more people to try forking Collect and
experimenting for themselves. It turned out to be dead simple. I'm
interested to hear all of your experiences. I'm also happy to contribute to
Brent's effort to make a comparable configuration if there is a list of
features desired from the server.

Regards,
Jeff

On Mon, Aug 29, 2016 at 9:19 AM, Daniel Kayiwa kayiwadaniel@gmail.com wrote:

I have seen a few projects realising that they made a mistake trying to
manage their own infrastructure servers, and hence having to go through the
pain of switching.
So basing on this experience, even if the resources are available, i would
vote for starting simple, with CI-as-a-service like Travis or Circle, etc.
Then switch, only if it turns out not to meet the actual needs.

On Mon, Aug 29, 2016 at 6:59 PM, Brent Atkinson brent.atkinson@gmail.com wrote:

Hi Carl,

Apologies for the delay responding. I don't know enough to say with
confidence which I would prefer at this point. I believe almost all of these
could work since most CI software systems are doing very similar things. My
sense is that it will boil down to whether we need/want full control and
have the resources to commit or whether we need/want to use a freely
available service and don't need as much control.

My inclination would be to use the CI-as-a-service tools unless it just
won't work for what we want it for. It's less of a commitment from a
time/money perspective unless it just can't work for what we're looking to
do.

The types of questions I would want to answer to have confidence in a
recommendation for ODK:

Do we have resources to build and maintain and monitor a build farm over
time?

No: I would favor CI-as-a-service like Travis/Circle - no host
provisioning or maintenance, minimal or no cost
Yes: Full control over all aspects of setup using a free-as-in-beer
server like Jenkins is more attractive

Are there parts of ODK that can not be made publicly available?

No: CI-as-a-service like Travis/Circle are still an option
Yes: Private build farm might be necessary, though could still be
possible to use CI-as-a-service depending on the specifics (may require more
$ or configuration to make it work)

What level of maturity are we looking to achieve with the CI setup?

Basic (basic builds on commit, test running/reporting): CI-as-a-service
is often a better option due to low/no cost and and no host maintenance
Intermediate (grid builds, additional analytics and trending): Depending
on specifics could favor CI-as-a-service for turn key simplicity, or private
setup for ease due to having full control over configuration and deployment
Advanced (complicated build pipelines, custom plugins, exotic build
environments): Usually favor the private setup due to controlling all
aspects of setup, however, pay options for the other tools are available and
may be as good or better as freely available tools like Jenkins

Do we need to handle secrets like API keys or signing certificates as
part of the build process (or deployment if we're doing full deployment
pipeline)?

Yes: CI-as-a-service like Travis/Circle allow for encrypting environment
variables and files so you can check them into projects and still keep their
contents private. The simplicity of CI-as-a-service starts to fade a bit
here. It may be easier/safer to run only on private servers depending on
pain involved or level of paranoia.
No: CI-as-a-service can be far faster if the setup is directly
supported. This relates to what I was testing before, and unfortunately, the
fact that the android API 19 wasn't installed already, meant I have more
work to do to make CI-as-a-service work. This doesn't necessarily make it
worse than a private setup though, since you have to configure/provision
everything in that case.

I'm sure there are other important details I am missing, but this should
give you an idea of the types of things to consider and have clarity on. At
this point, I still think it is worth seeing how far we can go with a
CI-as-a-service setup unless we can identify a deal breaker and/or
self-hosting on a longer time scale isn't feasible for the project.

If you all think it is worth while, I am willing to continue attempting
to setup Collect to build on both Travis and Circle. It might be possible
for me to fork Collect so I don't need special permissions and then submit
the configs back as pull requests. Then you all could review them, and
choose which to integrate, if any?

Brent

On Fri, Aug 26, 2016 at 7:33 PM, Carl Hartung chartung@nafundi.com wrote:

Hey Brent,
After your trial with CircleCI compared to your experience in Jenkins
and Travis, do you find yourself having a preference for one? or think one
would work better for Collect?

It sounds like there's generally more experience amonst the community
with Jenkins, so it might be easier to use/modify/troubleshoot if we go that
route.
-Carl

On Fri, Aug 26, 2016 at 7:40 AM, Brent Atkinson brent.atkinson@gmail.com wrote:

Hi Yaw,

Unfortunately, I can not do this with collect since I am not part of
the github organization.

However, I tried it with another android project. It did a good job of
inferring the basic setup, but not enough to successfully build the project.
It failed due to the android setup not being the version expected for the
project. Looking into a resolution, it appears Circle is very similar to
TravisCI. You have to specify additional specifications and/or commands in a
special yaml file in the repository. Also, the host is configured fresh from
a base image every time. Android SDK commands need to be run to install
build tools or API before the build commands, which increases the build
times considerably compared to a base image customized to the application.
There are ways to ask CircleCI to cache certain directories, which can limit
the effects of this.

I think this would work, but I don't see anything specific to CircleCI
that makes it better than others for android development. I guess the big
items would be:

Android SDK and NDK are pre-installed (though may need to use commands
to install other versions anyway)
A working emulator configuration is pre-installed through AVD

That's about it. If the build config doesn't match, you still need to
re-configure the host. Deployment appears to be through normal gradle
plugins, which would work for any build system.

The basic instructions for building android apps:
https://circleci.com/docs/android/
A description of how caching works:
https://circleci.com/docs/how-cache-works/

Hope this helps,

Brent

On Fri, Aug 26, 2016 at 7:46 AM, Yaw Anokwa yanokwa@nafundi.com wrote:

Thanks for looking into CircleCI, Brent. My gut says that we should
try it first, if that ends up sucking, we can fallback switch to
Jenkins, warts and all. Do you have the cycles to give it a try on the
Collect repo?

Yaw

On Thu, Aug 25, 2016 at 2:37 PM, Brent Atkinson brent.atkinson@gmail.com wrote:

Sorry for the noise, but reading more on CircleCI, they claim that
they
allow you to do whatever you want on their environments. It probably
still
means you're stuck with their starting environments, but it seems
you at
least have full control over them.

Brent

On Thu, Aug 25, 2016 at 10:28 AM, Brent Atkinson brent.atkinson@gmail.com wrote:

Hi,

I have used Jenkins and Travis. I haven't used CircleCI, but it
seems
extremely similar in spirit to Travis (connect your GitHub project
and go,
add YAML for customization).

In my experience, the biggest difference between Jenkins and these
other
tools is that it is extremely flexible in terms of deployment. You
can setup
a single master on your machine, a massive master/slave setup in
the cloud,
or use as-a-service with something like CloudBees. My experience
with CIaaS
is that it's a perfect free option for projects that fit well
within the
templates, but once you start needing more exotic configurations
not being
able to fully control the environment makes them less attractive.

Brent

On Wednesday, August 24, 2016 at 4:01:54 AM UTC-4, Yaw Anokwa wrote:

This is great info. Looks like Jenkins is what most are using. My
light reading is that their Android integration isn't amazing.

Has anyone tried CircleCI? It visually looks better, has
reportedly
better Android support, and is free for OSS.

On Tue, Aug 23, 2016 at 10:53 PM, Matt Berg mlb...@gmail.com wrote:

We use Jenkins and Drone. Jenkins I believe offers a free
service for
OS
projects if you are ok with waiting for your builds in a queue.

Matt

On Aug 23, 2016 1:34 PM, "Jeffrey Beorse" jbe...@cs.washington.edu wrote:

Hi Yaw,

I'm not sure how familiar you are with what we're doing in ODK
2.0,
but
we're using Jenkins to decent success. I'd echo Chris's
endorsement of
Jenkins on EC2.

Jenkins is pretty powerful and gives you a lot of control over
the
details
of your build. There are vast amounts of plugins, including
integration with
Github, Gradle, Android Emulators, JaCoCo, etc. We're running
custom
scripts
to handle copying file dependencies, automating multi-emulator
test
suites,
controlling slave systems for UI tests, publishing binaries
through
Artifactory, graphing code coverage summaries, and more. We're
running
automatic builds on each push to the development or demo
branches,
including
building signed APKs. We still build our master branch release
binaries by
hand because we like to do some hand testing before the real
release,
but we
could easily build them with Jenkins too.

Its not all perfect, of course. As Chris implied, Jenkins can
be
pretty
finicky. With each version bump we seem to have to fix our
github
integration. Documentation can be spotty depending on the
plugin.
Emulators
misbehave, though this is probably more Google's fault.

I don't have any experience with Travis, so I can't compare the
two
systems. All I can say is we've had an overall positive
experience
with
Jenkins.

Regards,
Jeff

On Tue, Aug 23, 2016 at 8:50 AM, Sam Sudar suda...@gmail.com wrote:

I've used Travis github integration in the past for a small
project:

https://github.com/srsudar/odk-sms-bridge

You can see example build output here:

https://travis-ci.org/srsudar/odk-sms-bridge

I found it easy to work with. I believe I was building per
commit,
not
nightly. It isn't a complicated project, however, and I don't
know
what
it's like setting it up for publishing the nightly builds to a
location.

I have no experience building signed APKs automatically, so I
can't
speak
to Chris's points about key locations or automatic signing.

On Tue, Aug 23, 2016 at 5:37 AM, Christopher Robert cro...@surveycto.com wrote:

Hi Yaw,

We automate builds with Jenkins on AWS EC2. However, we have
always
built our Android apk separately for a couple of reasons:

We wanted to more tightly control the build environment,
including
the
version of Java.
We wanted to guard the key we used to sign the apk closely.
And we ran into trouble with the Android SDK on EC2
(something about
x64
EC2 environments).

For 3, there are blog posts like this one, AWS seems to have
embraced
Jenkins, and with their mobile SDK AWS is clearly trying to
accommodate
mobile developers. So I suspect that if we went back to try
it
again,
everything would be fine.

As for 1 and 2, I think that those are less of a concern now.
Back
in
2013 we were a bit less comfortable with our EC2/Linux skills
and so
we
preferred building with Maven on OSX. But now I think that we
could
have a
well-controlled environment on which we wouldn't mind housing
our
private
key.

So, I'd recommend Jenkins on EC2 -- though I will say that
it's not
uncommon for Jenkins to get OOM errors and need to be
restarted. We
keep
bumping up the memory on our dev server, but nothing seems to
be
quite what
Jenkins wants. (I think that it wants a large memory swap
file, but
we don't
have a local drive on that machine and so don't have a memory
swap
configured.)

Best,

Chris

On Tue, Aug 23, 2016 at 8:21 AM Yaw Anokwa yan...@nafundi.com wrote:

Hi all,

I'd like to get automated nightly builds for ODK Collect and
I'd
love
to hear from folks who've used continuous integration and
testing
on
Android apps.

I'm guessing the folks at Dimagi, Kobo, SurveyCTO, Ona, and
ELMO
all
have some experience here. What platform did you use? Would
you
recommend it?

Thanks,

Yaw

--
You received this message because you are subscribed to the
Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails
from it,
send
an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it,
send
an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it,
send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
If we keep uppermost in our minds the unkind and unjust acts of others, we
shall find it impossible to love them as Christ has loved us; but if our
thoughts dwell upon the wondrous love and pity of Christ for us, the same
spirit will flow out to others.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(Sam Sudar) #16

Yaw,

I couldn't get past that error on the default Collect repo. I had to
regenerate the wrapper by running gradle wrapper from the base directory
of the project to recreate the wrapper.

Sam

ยทยทยท On Wed, Sep 7, 2016 at 8:13 AM, Yaw Anokwa wrote:

Hi Jeff,

Forgive my ignorance, but when I point CircleCI at my Collect fork, it
blows up with a NoClassDefFoundError:
org/gradle/cli/CommandLineParser. The full trace is at
http://dpaste.com/3E2GQQ0.

Did you do any configuration in CircleCI to get it to build or was it
really set it and forget?

Thanks,

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Fri, Sep 2, 2016 at 3:53 AM, Jeffrey Beorse jbeorse@cs.washington.edu wrote:

Hi,

I made a couple personal forks of Collect and tried both Travis and
Circle
CI just to see how they work, for fun. Below is my experience, but I only
spent an hour or two with them, so take everything with some salt.
@Brent,
you should be able to fork Collect through the typical Github workflow
and
everything should work. You can also just pull Collect from opendatakit's
github and push to an empty repo of your own.

Between the two cloud CI options, I found Circle CI's Android support to
be
significantly smoother and easier to use. I believe Travis is still in
beta,
so this may improve, but as it stands now Circle CI is nicer in my
opinion.
With Circle CI I was able to sign up for an account, press go on my
Collect
fork, and have it successfully build. I didn't even need to push a yml
file
to my Github repo (though obviously we would need one for anything more
than
a proof of concept). With Travis I spent a lot of time fiddling with my
yml
and reading cryptic build failures when the equivalent Gradle commands
worked fine locally. I know Brent had issues with Circle CI missing an
Android API level, but you have to specify your API level in Travis too,
so
that doesn't like a win to me. I am not aware of any fundamental
differences
in their platforms, so more mature Android support seems as good a
reason as
any to pick Circle CI.

Coming from a Jenkins background, they both felt very bare bones to me.
Right away I wondered how we might run emulator tests on multiple
Android OS
versions (i.e. test on 4.3, 4.4, 5.0. 5.1, etc). What if we need
additional
scripting or build environment control? Brent addresses these types of
things in his third bullet point above. But Collect's code base, as it is
today, doesn't have any tests and doesn't need a customized build
environment. So is it worth the effort to maintain a Jenkins server to
have
these options in the future?

I agree with Brent's assessment above. Assuming we aren't afraid to
switch
to Jenkins down the road, my vote would be to choose the tool that meets
our
current needs with minimal effort and upgrade if a compelling reason
arises.

I'd definitely encourage more people to try forking Collect and
experimenting for themselves. It turned out to be dead simple. I'm
interested to hear all of your experiences. I'm also happy to contribute
to
Brent's effort to make a comparable configuration if there is a list of
features desired from the server.

Regards,
Jeff

On Mon, Aug 29, 2016 at 9:19 AM, Daniel Kayiwa kayiwadaniel@gmail.com wrote:

I have seen a few projects realising that they made a mistake trying to
manage their own infrastructure servers, and hence having to go through
the

pain of switching.
So basing on this experience, even if the resources are available, i
would

vote for starting simple, with CI-as-a-service like Travis or Circle,
etc.

Then switch, only if it turns out not to meet the actual needs.

On Mon, Aug 29, 2016 at 6:59 PM, Brent Atkinson < brent.atkinson@gmail.com> wrote:

Hi Carl,

Apologies for the delay responding. I don't know enough to say with
confidence which I would prefer at this point. I believe almost all of
these

could work since most CI software systems are doing very similar
things. My

sense is that it will boil down to whether we need/want full control
and

have the resources to commit or whether we need/want to use a freely
available service and don't need as much control.

My inclination would be to use the CI-as-a-service tools unless it just
won't work for what we want it for. It's less of a commitment from a
time/money perspective unless it just can't work for what we're
looking to

do.

The types of questions I would want to answer to have confidence in a
recommendation for ODK:

Do we have resources to build and maintain and monitor a build farm
over

time?

No: I would favor CI-as-a-service like Travis/Circle - no host
provisioning or maintenance, minimal or no cost
Yes: Full control over all aspects of setup using a free-as-in-beer
server like Jenkins is more attractive

Are there parts of ODK that can not be made publicly available?

No: CI-as-a-service like Travis/Circle are still an option
Yes: Private build farm might be necessary, though could still be
possible to use CI-as-a-service depending on the specifics (may
require more

$ or configuration to make it work)

What level of maturity are we looking to achieve with the CI setup?

Basic (basic builds on commit, test running/reporting): CI-as-a-service
is often a better option due to low/no cost and and no host maintenance
Intermediate (grid builds, additional analytics and trending):
Depending

on specifics could favor CI-as-a-service for turn key simplicity, or
private

setup for ease due to having full control over configuration and
deployment

Advanced (complicated build pipelines, custom plugins, exotic build
environments): Usually favor the private setup due to controlling all
aspects of setup, however, pay options for the other tools are
available and

may be as good or better as freely available tools like Jenkins

Do we need to handle secrets like API keys or signing certificates as
part of the build process (or deployment if we're doing full deployment
pipeline)?

Yes: CI-as-a-service like Travis/Circle allow for encrypting
environment

variables and files so you can check them into projects and still keep
their

contents private. The simplicity of CI-as-a-service starts to fade a
bit

here. It may be easier/safer to run only on private servers depending
on

pain involved or level of paranoia.
No: CI-as-a-service can be far faster if the setup is directly
supported. This relates to what I was testing before, and
unfortunately, the

fact that the android API 19 wasn't installed already, meant I have
more

work to do to make CI-as-a-service work. This doesn't necessarily make
it

worse than a private setup though, since you have to
configure/provision

everything in that case.

I'm sure there are other important details I am missing, but this
should

give you an idea of the types of things to consider and have clarity
on. At

this point, I still think it is worth seeing how far we can go with a
CI-as-a-service setup unless we can identify a deal breaker and/or
self-hosting on a longer time scale isn't feasible for the project.

If you all think it is worth while, I am willing to continue attempting
to setup Collect to build on both Travis and Circle. It might be
possible

for me to fork Collect so I don't need special permissions and then
submit

the configs back as pull requests. Then you all could review them, and
choose which to integrate, if any?

Brent

On Fri, Aug 26, 2016 at 7:33 PM, Carl Hartung chartung@nafundi.com wrote:

Hey Brent,
After your trial with CircleCI compared to your experience in Jenkins
and Travis, do you find yourself having a preference for one? or
think one

would work better for Collect?

It sounds like there's generally more experience amonst the community
with Jenkins, so it might be easier to use/modify/troubleshoot if we
go that

route.
-Carl

On Fri, Aug 26, 2016 at 7:40 AM, Brent Atkinson brent.atkinson@gmail.com wrote:

Hi Yaw,

Unfortunately, I can not do this with collect since I am not part of
the github organization.

However, I tried it with another android project. It did a good job
of

inferring the basic setup, but not enough to successfully build the
project.

It failed due to the android setup not being the version expected
for the

project. Looking into a resolution, it appears Circle is very
similar to

TravisCI. You have to specify additional specifications and/or
commands in a

special yaml file in the repository. Also, the host is configured
fresh from

a base image every time. Android SDK commands need to be run to
install

build tools or API before the build commands, which increases the
build

times considerably compared to a base image customized to the
application.

There are ways to ask CircleCI to cache certain directories, which
can limit

the effects of this.

I think this would work, but I don't see anything specific to
CircleCI

that makes it better than others for android development. I guess
the big

items would be:

Android SDK and NDK are pre-installed (though may need to use
commands

to install other versions anyway)
A working emulator configuration is pre-installed through AVD

That's about it. If the build config doesn't match, you still need to
re-configure the host. Deployment appears to be through normal gradle
plugins, which would work for any build system.

The basic instructions for building android apps:
https://circleci.com/docs/android/
A description of how caching works:
https://circleci.com/docs/how-cache-works/

Hope this helps,

Brent

On Fri, Aug 26, 2016 at 7:46 AM, Yaw Anokwa yanokwa@nafundi.com wrote:

Thanks for looking into CircleCI, Brent. My gut says that we should
try it first, if that ends up sucking, we can fallback switch to
Jenkins, warts and all. Do you have the cycles to give it a try on
the

Collect repo?

Yaw

On Thu, Aug 25, 2016 at 2:37 PM, Brent Atkinson brent.atkinson@gmail.com wrote:

Sorry for the noise, but reading more on CircleCI, they claim that
they
allow you to do whatever you want on their environments. It
probably

still
means you're stuck with their starting environments, but it seems
you at
least have full control over them.

Brent

On Thu, Aug 25, 2016 at 10:28 AM, Brent Atkinson brent.atkinson@gmail.com wrote:

Hi,

I have used Jenkins and Travis. I haven't used CircleCI, but it
seems
extremely similar in spirit to Travis (connect your GitHub
project

and go,
add YAML for customization).

In my experience, the biggest difference between Jenkins and
these

other
tools is that it is extremely flexible in terms of deployment.
You

can setup
a single master on your machine, a massive master/slave setup in
the cloud,
or use as-a-service with something like CloudBees. My experience
with CIaaS
is that it's a perfect free option for projects that fit well
within the
templates, but once you start needing more exotic configurations
not being
able to fully control the environment makes them less attractive.

Brent

On Wednesday, August 24, 2016 at 4:01:54 AM UTC-4, Yaw Anokwa wrote:

This is great info. Looks like Jenkins is what most are using.
My

light reading is that their Android integration isn't amazing.

Has anyone tried CircleCI? It visually looks better, has
reportedly
better Android support, and is free for OSS.

On Tue, Aug 23, 2016 at 10:53 PM, Matt Berg mlb...@gmail.com wrote:

We use Jenkins and Drone. Jenkins I believe offers a free
service for
OS
projects if you are ok with waiting for your builds in a
queue.

Matt

On Aug 23, 2016 1:34 PM, "Jeffrey Beorse" jbe...@cs.washington.edu wrote:

Hi Yaw,

I'm not sure how familiar you are with what we're doing in
ODK

2.0,
but
we're using Jenkins to decent success. I'd echo Chris's
endorsement of
Jenkins on EC2.

Jenkins is pretty powerful and gives you a lot of control
over

the
details
of your build. There are vast amounts of plugins, including
integration with
Github, Gradle, Android Emulators, JaCoCo, etc. We're running
custom
scripts
to handle copying file dependencies, automating
multi-emulator

test
suites,
controlling slave systems for UI tests, publishing binaries
through
Artifactory, graphing code coverage summaries, and more.
We're

running
automatic builds on each push to the development or demo
branches,
including
building signed APKs. We still build our master branch
release

binaries by
hand because we like to do some hand testing before the real
release,
but we
could easily build them with Jenkins too.

Its not all perfect, of course. As Chris implied, Jenkins can
be
pretty
finicky. With each version bump we seem to have to fix our
github
integration. Documentation can be spotty depending on the
plugin.
Emulators
misbehave, though this is probably more Google's fault.

I don't have any experience with Travis, so I can't compare
the

two
systems. All I can say is we've had an overall positive
experience
with
Jenkins.

Regards,
Jeff

On Tue, Aug 23, 2016 at 8:50 AM, Sam Sudar < suda...@gmail.com> wrote:

I've used Travis github integration in the past for a small
project:

https://github.com/srsudar/odk-sms-bridge

You can see example build output here:

https://travis-ci.org/srsudar/odk-sms-bridge

I found it easy to work with. I believe I was building per
commit,
not
nightly. It isn't a complicated project, however, and I
don't

know
what
it's like setting it up for publishing the nightly builds
to a

location.

I have no experience building signed APKs automatically, so
I

can't
speak
to Chris's points about key locations or automatic signing.

On Tue, Aug 23, 2016 at 5:37 AM, Christopher Robert cro...@surveycto.com wrote:

Hi Yaw,

We automate builds with Jenkins on AWS EC2. However, we
have

always
built our Android apk separately for a couple of reasons:

We wanted to more tightly control the build environment,
including
the
version of Java.
We wanted to guard the key we used to sign the apk closely.
And we ran into trouble with the Android SDK on EC2
(something about
x64
EC2 environments).

For 3, there are blog posts like this one, AWS seems to
have

embraced
Jenkins, and with their mobile SDK AWS is clearly trying to
accommodate
mobile developers. So I suspect that if we went back to try
it
again,
everything would be fine.

As for 1 and 2, I think that those are less of a concern
now.

Back
in
2013 we were a bit less comfortable with our EC2/Linux
skills

and so
we
preferred building with Maven on OSX. But now I think that
we

could
have a
well-controlled environment on which we wouldn't mind
housing

our
private
key.

So, I'd recommend Jenkins on EC2 -- though I will say that
it's not
uncommon for Jenkins to get OOM errors and need to be
restarted. We
keep
bumping up the memory on our dev server, but nothing seems
to

be
quite what
Jenkins wants. (I think that it wants a large memory swap
file, but
we don't
have a local drive on that machine and so don't have a
memory

swap
configured.)

Best,

Chris

On Tue, Aug 23, 2016 at 8:21 AM Yaw Anokwa yan...@nafundi.com wrote:

Hi all,

I'd like to get automated nightly builds for ODK Collect
and

I'd
love
to hear from folks who've used continuous integration and
testing
on
Android apps.

I'm guessing the folks at Dimagi, Kobo, SurveyCTO, Ona,
and

ELMO
all
have some experience here. What platform did you use?
Would

you
recommend it?

Thanks,

Yaw

--
You received this message because you are subscribed to
the

Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails
from it,
send
an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/
optout.

--
You received this message because you are subscribed to the
Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails
from

it,
send
an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout
.

--
You received this message because you are subscribed to the
Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails
from

it,
send an
email to opendatakit-developers+
unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
If we keep uppermost in our minds the unkind and unjust acts of others,
we

shall find it impossible to love them as Christ has loved us; but if our
thoughts dwell upon the wondrous love and pity of Christ for us, the
same

spirit will flow out to others.

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(Sam Sudar) #17

I have no experience with Circle CI and no opinion on which we should
choose.

In case others are interested, however, I have a very thin repackaging of
Collect that I set up with Travis integration this weekend. I chose Travis
over Circle CI only because I'm more familiar with Travis.

Github: https://github.com/srsudar/MamasDelRioAndroid/
Travis: https://travis-ci.org/srsudar/MamasDelRioAndroid

It has Robolectric tests for the modules that I've added. It has Google
Analytics integrated, which requires a google-services.json file to be
present in the app directory. This is confidential and normally not
versioned but is required for the build. I added it as an encrypted file,
following these instructions
https://docs.travis-ci.com/user/encrypting-files/. There were a few
gotchas, but overall it was pretty painless.

You can see the full build instructions in the travis.yaml
https://github.com/srsudar/MamasDelRioAndroid/blob/master/.travis.yml
file in the repo. It is based in part on Robolectric's travis.yaml
https://github.com/robolectric/robolectric/blob/master/.travis.yml.

Sam

ยทยทยท On Wed, Sep 7, 2016 at 8:32 AM, Sam Sudar wrote:

Yaw,

I couldn't get past that error on the default Collect repo. I had to
regenerate the wrapper by running gradle wrapper from the base directory
of the project to recreate the wrapper.

Sam

On Wed, Sep 7, 2016 at 8:13 AM, Yaw Anokwa yanokwa@nafundi.com wrote:

Hi Jeff,

Forgive my ignorance, but when I point CircleCI at my Collect fork, it
blows up with a NoClassDefFoundError:
org/gradle/cli/CommandLineParser. The full trace is at
http://dpaste.com/3E2GQQ0.

Did you do any configuration in CircleCI to get it to build or was it
really set it and forget?

Thanks,

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Fri, Sep 2, 2016 at 3:53 AM, Jeffrey Beorse jbeorse@cs.washington.edu wrote:

Hi,

I made a couple personal forks of Collect and tried both Travis and
Circle
CI just to see how they work, for fun. Below is my experience, but I
only
spent an hour or two with them, so take everything with some salt.
@Brent,
you should be able to fork Collect through the typical Github workflow
and
everything should work. You can also just pull Collect from
opendatakit's
github and push to an empty repo of your own.

Between the two cloud CI options, I found Circle CI's Android support
to be
significantly smoother and easier to use. I believe Travis is still in
beta,
so this may improve, but as it stands now Circle CI is nicer in my
opinion.
With Circle CI I was able to sign up for an account, press go on my
Collect
fork, and have it successfully build. I didn't even need to push a yml
file
to my Github repo (though obviously we would need one for anything more
than
a proof of concept). With Travis I spent a lot of time fiddling with my
yml
and reading cryptic build failures when the equivalent Gradle commands
worked fine locally. I know Brent had issues with Circle CI missing an
Android API level, but you have to specify your API level in Travis
too, so
that doesn't like a win to me. I am not aware of any fundamental
differences
in their platforms, so more mature Android support seems as good a
reason as
any to pick Circle CI.

Coming from a Jenkins background, they both felt very bare bones to me.
Right away I wondered how we might run emulator tests on multiple
Android OS
versions (i.e. test on 4.3, 4.4, 5.0. 5.1, etc). What if we need
additional
scripting or build environment control? Brent addresses these types of
things in his third bullet point above. But Collect's code base, as it
is
today, doesn't have any tests and doesn't need a customized build
environment. So is it worth the effort to maintain a Jenkins server to
have
these options in the future?

I agree with Brent's assessment above. Assuming we aren't afraid to
switch
to Jenkins down the road, my vote would be to choose the tool that
meets our
current needs with minimal effort and upgrade if a compelling reason
arises.

I'd definitely encourage more people to try forking Collect and
experimenting for themselves. It turned out to be dead simple. I'm
interested to hear all of your experiences. I'm also happy to
contribute to
Brent's effort to make a comparable configuration if there is a list of
features desired from the server.

Regards,
Jeff

On Mon, Aug 29, 2016 at 9:19 AM, Daniel Kayiwa kayiwadaniel@gmail.com wrote:

I have seen a few projects realising that they made a mistake trying to
manage their own infrastructure servers, and hence having to go
through the

pain of switching.
So basing on this experience, even if the resources are available, i
would

vote for starting simple, with CI-as-a-service like Travis or Circle,
etc.

Then switch, only if it turns out not to meet the actual needs.

On Mon, Aug 29, 2016 at 6:59 PM, Brent Atkinson < brent.atkinson@gmail.com> wrote:

Hi Carl,

Apologies for the delay responding. I don't know enough to say with
confidence which I would prefer at this point. I believe almost all
of these

could work since most CI software systems are doing very similar
things. My

sense is that it will boil down to whether we need/want full control
and

have the resources to commit or whether we need/want to use a freely
available service and don't need as much control.

My inclination would be to use the CI-as-a-service tools unless it
just

won't work for what we want it for. It's less of a commitment from a
time/money perspective unless it just can't work for what we're
looking to

do.

The types of questions I would want to answer to have confidence in a
recommendation for ODK:

Do we have resources to build and maintain and monitor a build farm
over

time?

No: I would favor CI-as-a-service like Travis/Circle - no host
provisioning or maintenance, minimal or no cost
Yes: Full control over all aspects of setup using a free-as-in-beer
server like Jenkins is more attractive

Are there parts of ODK that can not be made publicly available?

No: CI-as-a-service like Travis/Circle are still an option
Yes: Private build farm might be necessary, though could still be
possible to use CI-as-a-service depending on the specifics (may
require more

$ or configuration to make it work)

What level of maturity are we looking to achieve with the CI setup?

Basic (basic builds on commit, test running/reporting):
CI-as-a-service

is often a better option due to low/no cost and and no host
maintenance

Intermediate (grid builds, additional analytics and trending):
Depending

on specifics could favor CI-as-a-service for turn key simplicity, or
private

setup for ease due to having full control over configuration and
deployment

Advanced (complicated build pipelines, custom plugins, exotic build
environments): Usually favor the private setup due to controlling all
aspects of setup, however, pay options for the other tools are
available and

may be as good or better as freely available tools like Jenkins

Do we need to handle secrets like API keys or signing certificates as
part of the build process (or deployment if we're doing full
deployment

pipeline)?

Yes: CI-as-a-service like Travis/Circle allow for encrypting
environment

variables and files so you can check them into projects and still
keep their

contents private. The simplicity of CI-as-a-service starts to fade a
bit

here. It may be easier/safer to run only on private servers depending
on

pain involved or level of paranoia.
No: CI-as-a-service can be far faster if the setup is directly
supported. This relates to what I was testing before, and
unfortunately, the

fact that the android API 19 wasn't installed already, meant I have
more

work to do to make CI-as-a-service work. This doesn't necessarily
make it

worse than a private setup though, since you have to
configure/provision

everything in that case.

I'm sure there are other important details I am missing, but this
should

give you an idea of the types of things to consider and have clarity
on. At

this point, I still think it is worth seeing how far we can go with a
CI-as-a-service setup unless we can identify a deal breaker and/or
self-hosting on a longer time scale isn't feasible for the project.

If you all think it is worth while, I am willing to continue
attempting

to setup Collect to build on both Travis and Circle. It might be
possible

for me to fork Collect so I don't need special permissions and then
submit

the configs back as pull requests. Then you all could review them, and
choose which to integrate, if any?

Brent

On Fri, Aug 26, 2016 at 7:33 PM, Carl Hartung chartung@nafundi.com wrote:

Hey Brent,
After your trial with CircleCI compared to your experience in Jenkins
and Travis, do you find yourself having a preference for one? or
think one

would work better for Collect?

It sounds like there's generally more experience amonst the community
with Jenkins, so it might be easier to use/modify/troubleshoot if we
go that

route.
-Carl

On Fri, Aug 26, 2016 at 7:40 AM, Brent Atkinson brent.atkinson@gmail.com wrote:

Hi Yaw,

Unfortunately, I can not do this with collect since I am not part of
the github organization.

However, I tried it with another android project. It did a good job
of

inferring the basic setup, but not enough to successfully build the
project.

It failed due to the android setup not being the version expected
for the

project. Looking into a resolution, it appears Circle is very
similar to

TravisCI. You have to specify additional specifications and/or
commands in a

special yaml file in the repository. Also, the host is configured
fresh from

a base image every time. Android SDK commands need to be run to
install

build tools or API before the build commands, which increases the
build

times considerably compared to a base image customized to the
application.

There are ways to ask CircleCI to cache certain directories, which
can limit

the effects of this.

I think this would work, but I don't see anything specific to
CircleCI

that makes it better than others for android development. I guess
the big

items would be:

Android SDK and NDK are pre-installed (though may need to use
commands

to install other versions anyway)
A working emulator configuration is pre-installed through AVD

That's about it. If the build config doesn't match, you still need
to

re-configure the host. Deployment appears to be through normal
gradle

plugins, which would work for any build system.

The basic instructions for building android apps:
https://circleci.com/docs/android/
A description of how caching works:
https://circleci.com/docs/how-cache-works/

Hope this helps,

Brent

On Fri, Aug 26, 2016 at 7:46 AM, Yaw Anokwa yanokwa@nafundi.com wrote:

Thanks for looking into CircleCI, Brent. My gut says that we should
try it first, if that ends up sucking, we can fallback switch to
Jenkins, warts and all. Do you have the cycles to give it a try on
the

Collect repo?

Yaw

On Thu, Aug 25, 2016 at 2:37 PM, Brent Atkinson brent.atkinson@gmail.com wrote:

Sorry for the noise, but reading more on CircleCI, they claim
that

they
allow you to do whatever you want on their environments. It
probably

still
means you're stuck with their starting environments, but it seems
you at
least have full control over them.

Brent

On Thu, Aug 25, 2016 at 10:28 AM, Brent Atkinson brent.atkinson@gmail.com wrote:

Hi,

I have used Jenkins and Travis. I haven't used CircleCI, but it
seems
extremely similar in spirit to Travis (connect your GitHub
project

and go,
add YAML for customization).

In my experience, the biggest difference between Jenkins and
these

other
tools is that it is extremely flexible in terms of deployment.
You

can setup
a single master on your machine, a massive master/slave setup in
the cloud,
or use as-a-service with something like CloudBees. My experience
with CIaaS
is that it's a perfect free option for projects that fit well
within the
templates, but once you start needing more exotic configurations
not being
able to fully control the environment makes them less
attractive.

Brent

On Wednesday, August 24, 2016 at 4:01:54 AM UTC-4, Yaw Anokwa wrote:

This is great info. Looks like Jenkins is what most are using.
My

light reading is that their Android integration isn't amazing.

Has anyone tried CircleCI? It visually looks better, has
reportedly
better Android support, and is free for OSS.

On Tue, Aug 23, 2016 at 10:53 PM, Matt Berg mlb...@gmail.com wrote:

We use Jenkins and Drone. Jenkins I believe offers a free
service for
OS
projects if you are ok with waiting for your builds in a
queue.

Matt

On Aug 23, 2016 1:34 PM, "Jeffrey Beorse" jbe...@cs.washington.edu wrote:

Hi Yaw,

I'm not sure how familiar you are with what we're doing in
ODK

2.0,
but
we're using Jenkins to decent success. I'd echo Chris's
endorsement of
Jenkins on EC2.

Jenkins is pretty powerful and gives you a lot of control
over

the
details
of your build. There are vast amounts of plugins, including
integration with
Github, Gradle, Android Emulators, JaCoCo, etc. We're
running

custom
scripts
to handle copying file dependencies, automating
multi-emulator

test
suites,
controlling slave systems for UI tests, publishing binaries
through
Artifactory, graphing code coverage summaries, and more.
We're

running
automatic builds on each push to the development or demo
branches,
including
building signed APKs. We still build our master branch
release

binaries by
hand because we like to do some hand testing before the real
release,
but we
could easily build them with Jenkins too.

Its not all perfect, of course. As Chris implied, Jenkins
can

be
pretty
finicky. With each version bump we seem to have to fix our
github
integration. Documentation can be spotty depending on the
plugin.
Emulators
misbehave, though this is probably more Google's fault.

I don't have any experience with Travis, so I can't compare
the

two
systems. All I can say is we've had an overall positive
experience
with
Jenkins.

Regards,
Jeff

On Tue, Aug 23, 2016 at 8:50 AM, Sam Sudar < suda...@gmail.com> wrote:

I've used Travis github integration in the past for a small
project:

https://github.com/srsudar/odk-sms-bridge

You can see example build output here:

https://travis-ci.org/srsudar/odk-sms-bridge

I found it easy to work with. I believe I was building per
commit,
not
nightly. It isn't a complicated project, however, and I
don't

know
what
it's like setting it up for publishing the nightly builds
to a

location.

I have no experience building signed APKs automatically,
so I

can't
speak
to Chris's points about key locations or automatic signing.

On Tue, Aug 23, 2016 at 5:37 AM, Christopher Robert cro...@surveycto.com wrote:

Hi Yaw,

We automate builds with Jenkins on AWS EC2. However, we
have

always
built our Android apk separately for a couple of reasons:

We wanted to more tightly control the build environment,
including
the
version of Java.
We wanted to guard the key we used to sign the apk
closely.

And we ran into trouble with the Android SDK on EC2
(something about
x64
EC2 environments).

For 3, there are blog posts like this one, AWS seems to
have

embraced
Jenkins, and with their mobile SDK AWS is clearly trying
to

accommodate
mobile developers. So I suspect that if we went back to
try

it
again,
everything would be fine.

As for 1 and 2, I think that those are less of a concern
now.

Back
in
2013 we were a bit less comfortable with our EC2/Linux
skills

and so
we
preferred building with Maven on OSX. But now I think
that we

could
have a
well-controlled environment on which we wouldn't mind
housing

our
private
key.

So, I'd recommend Jenkins on EC2 -- though I will say that
it's not
uncommon for Jenkins to get OOM errors and need to be
restarted. We
keep
bumping up the memory on our dev server, but nothing
seems to

be
quite what
Jenkins wants. (I think that it wants a large memory swap
file, but
we don't
have a local drive on that machine and so don't have a
memory

swap
configured.)

Best,

Chris

On Tue, Aug 23, 2016 at 8:21 AM Yaw Anokwa yan...@nafundi.com wrote:

Hi all,

I'd like to get automated nightly builds for ODK Collect
and

I'd
love
to hear from folks who've used continuous integration and
testing
on
Android apps.

I'm guessing the folks at Dimagi, Kobo, SurveyCTO, Ona,
and

ELMO
all
have some experience here. What platform did you use?
Would

you
recommend it?

Thanks,

Yaw

--
You received this message because you are subscribed to
the

Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails
from it,
send
an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/op
tout.

--
You received this message because you are subscribed to
the

Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails
from

it,
send
an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/op
tout.

--
You received this message because you are subscribed to the
Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails
from

it,
send an
email to opendatakit-developers+unsubsc
ribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout
.

--
You received this message because you are subscribed to the
Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails
from

it, send
an
email to opendatakit-developers+unsubsc
ribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it,

send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
If we keep uppermost in our minds the unkind and unjust acts of
others, we

shall find it impossible to love them as Christ has loved us; but if
our

thoughts dwell upon the wondrous love and pity of Christ for us, the
same

spirit will flow out to others.

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(Jeff Beorse) #18

Sam is correct, the Gradle wrapper was out of date. It would fail even on
local command line builds (though of course not on Android Studio builds,
as Android Studio doesn't use the wrapper). I went ahead and updated the
Gradle wrapper. The process is exactly as Sam described: after installing
Gradle on your system, run 'gradle wrapper' at the root level of Collect.

The repo is currently in the exact state that built for me with Circle CI.
If you turn it back on, I believe it should pass.

Regards,
Jeff

ยทยทยท On Wed, Sep 7, 2016 at 8:55 AM, Sam Sudar wrote:

I have no experience with Circle CI and no opinion on which we should
choose.

In case others are interested, however, I have a very thin repackaging of
Collect that I set up with Travis integration this weekend. I chose Travis
over Circle CI only because I'm more familiar with Travis.

Github: https://github.com/srsudar/MamasDelRioAndroid/
Travis: https://travis-ci.org/srsudar/MamasDelRioAndroid

It has Robolectric tests for the modules that I've added. It has Google
Analytics integrated, which requires a google-services.json file to be
present in the app directory. This is confidential and normally not
versioned but is required for the build. I added it as an encrypted file,
following these instructions
https://docs.travis-ci.com/user/encrypting-files/. There were a few
gotchas, but overall it was pretty painless.

You can see the full build instructions in the travis.yaml
https://github.com/srsudar/MamasDelRioAndroid/blob/master/.travis.yml
file in the repo. It is based in part on Robolectric's travis.yaml
https://github.com/robolectric/robolectric/blob/master/.travis.yml.

Sam

On Wed, Sep 7, 2016 at 8:32 AM, Sam Sudar sudar.sam@gmail.com wrote:

Yaw,

I couldn't get past that error on the default Collect repo. I had to
regenerate the wrapper by running gradle wrapper from the base directory
of the project to recreate the wrapper.

Sam

On Wed, Sep 7, 2016 at 8:13 AM, Yaw Anokwa yanokwa@nafundi.com wrote:

Hi Jeff,

Forgive my ignorance, but when I point CircleCI at my Collect fork, it
blows up with a NoClassDefFoundError:
org/gradle/cli/CommandLineParser. The full trace is at
http://dpaste.com/3E2GQQ0.

Did you do any configuration in CircleCI to get it to build or was it
really set it and forget?

Thanks,

Yaw

Need ODK consultants? Nafundi provides form design, server setup,
in-field training, and software development for ODK. Go to
https://nafundi.com to get started.

On Fri, Sep 2, 2016 at 3:53 AM, Jeffrey Beorse jbeorse@cs.washington.edu wrote:

Hi,

I made a couple personal forks of Collect and tried both Travis and
Circle
CI just to see how they work, for fun. Below is my experience, but I
only
spent an hour or two with them, so take everything with some salt.
@Brent,
you should be able to fork Collect through the typical Github workflow
and
everything should work. You can also just pull Collect from
opendatakit's
github and push to an empty repo of your own.

Between the two cloud CI options, I found Circle CI's Android support
to be
significantly smoother and easier to use. I believe Travis is still in
beta,
so this may improve, but as it stands now Circle CI is nicer in my
opinion.
With Circle CI I was able to sign up for an account, press go on my
Collect
fork, and have it successfully build. I didn't even need to push a yml
file
to my Github repo (though obviously we would need one for anything
more than
a proof of concept). With Travis I spent a lot of time fiddling with
my yml
and reading cryptic build failures when the equivalent Gradle commands
worked fine locally. I know Brent had issues with Circle CI missing an
Android API level, but you have to specify your API level in Travis
too, so
that doesn't like a win to me. I am not aware of any fundamental
differences
in their platforms, so more mature Android support seems as good a
reason as
any to pick Circle CI.

Coming from a Jenkins background, they both felt very bare bones to me.
Right away I wondered how we might run emulator tests on multiple
Android OS
versions (i.e. test on 4.3, 4.4, 5.0. 5.1, etc). What if we need
additional
scripting or build environment control? Brent addresses these types of
things in his third bullet point above. But Collect's code base, as it
is
today, doesn't have any tests and doesn't need a customized build
environment. So is it worth the effort to maintain a Jenkins server to
have
these options in the future?

I agree with Brent's assessment above. Assuming we aren't afraid to
switch
to Jenkins down the road, my vote would be to choose the tool that
meets our
current needs with minimal effort and upgrade if a compelling reason
arises.

I'd definitely encourage more people to try forking Collect and
experimenting for themselves. It turned out to be dead simple. I'm
interested to hear all of your experiences. I'm also happy to
contribute to
Brent's effort to make a comparable configuration if there is a list of
features desired from the server.

Regards,
Jeff

On Mon, Aug 29, 2016 at 9:19 AM, Daniel Kayiwa <kayiwadaniel@gmail.com wrote:

I have seen a few projects realising that they made a mistake trying
to

manage their own infrastructure servers, and hence having to go
through the

pain of switching.
So basing on this experience, even if the resources are available, i
would

vote for starting simple, with CI-as-a-service like Travis or Circle,
etc.

Then switch, only if it turns out not to meet the actual needs.

On Mon, Aug 29, 2016 at 6:59 PM, Brent Atkinson < brent.atkinson@gmail.com> wrote:

Hi Carl,

Apologies for the delay responding. I don't know enough to say with
confidence which I would prefer at this point. I believe almost all
of these

could work since most CI software systems are doing very similar
things. My

sense is that it will boil down to whether we need/want full control
and

have the resources to commit or whether we need/want to use a freely
available service and don't need as much control.

My inclination would be to use the CI-as-a-service tools unless it
just

won't work for what we want it for. It's less of a commitment from a
time/money perspective unless it just can't work for what we're
looking to

do.

The types of questions I would want to answer to have confidence in a
recommendation for ODK:

Do we have resources to build and maintain and monitor a build farm
over

time?

No: I would favor CI-as-a-service like Travis/Circle - no host
provisioning or maintenance, minimal or no cost
Yes: Full control over all aspects of setup using a free-as-in-beer
server like Jenkins is more attractive

Are there parts of ODK that can not be made publicly available?

No: CI-as-a-service like Travis/Circle are still an option
Yes: Private build farm might be necessary, though could still be
possible to use CI-as-a-service depending on the specifics (may
require more

$ or configuration to make it work)

What level of maturity are we looking to achieve with the CI setup?

Basic (basic builds on commit, test running/reporting):
CI-as-a-service

is often a better option due to low/no cost and and no host
maintenance

Intermediate (grid builds, additional analytics and trending):
Depending

on specifics could favor CI-as-a-service for turn key simplicity, or
private

setup for ease due to having full control over configuration and
deployment

Advanced (complicated build pipelines, custom plugins, exotic build
environments): Usually favor the private setup due to controlling all
aspects of setup, however, pay options for the other tools are
available and

may be as good or better as freely available tools like Jenkins

Do we need to handle secrets like API keys or signing certificates as
part of the build process (or deployment if we're doing full
deployment

pipeline)?

Yes: CI-as-a-service like Travis/Circle allow for encrypting
environment

variables and files so you can check them into projects and still
keep their

contents private. The simplicity of CI-as-a-service starts to fade a
bit

here. It may be easier/safer to run only on private servers
depending on

pain involved or level of paranoia.
No: CI-as-a-service can be far faster if the setup is directly
supported. This relates to what I was testing before, and
unfortunately, the

fact that the android API 19 wasn't installed already, meant I have
more

work to do to make CI-as-a-service work. This doesn't necessarily
make it

worse than a private setup though, since you have to
configure/provision

everything in that case.

I'm sure there are other important details I am missing, but this
should

give you an idea of the types of things to consider and have clarity
on. At

this point, I still think it is worth seeing how far we can go with a
CI-as-a-service setup unless we can identify a deal breaker and/or
self-hosting on a longer time scale isn't feasible for the project.

If you all think it is worth while, I am willing to continue
attempting

to setup Collect to build on both Travis and Circle. It might be
possible

for me to fork Collect so I don't need special permissions and then
submit

the configs back as pull requests. Then you all could review them,
and

choose which to integrate, if any?

Brent

On Fri, Aug 26, 2016 at 7:33 PM, Carl Hartung chartung@nafundi.com wrote:

Hey Brent,
After your trial with CircleCI compared to your experience in
Jenkins

and Travis, do you find yourself having a preference for one? or
think one

would work better for Collect?

It sounds like there's generally more experience amonst the
community

with Jenkins, so it might be easier to use/modify/troubleshoot if
we go that

route.
-Carl

On Fri, Aug 26, 2016 at 7:40 AM, Brent Atkinson brent.atkinson@gmail.com wrote:

Hi Yaw,

Unfortunately, I can not do this with collect since I am not part
of

the github organization.

However, I tried it with another android project. It did a good
job of

inferring the basic setup, but not enough to successfully build
the project.

It failed due to the android setup not being the version expected
for the

project. Looking into a resolution, it appears Circle is very
similar to

TravisCI. You have to specify additional specifications and/or
commands in a

special yaml file in the repository. Also, the host is configured
fresh from

a base image every time. Android SDK commands need to be run to
install

build tools or API before the build commands, which increases the
build

times considerably compared to a base image customized to the
application.

There are ways to ask CircleCI to cache certain directories, which
can limit

the effects of this.

I think this would work, but I don't see anything specific to
CircleCI

that makes it better than others for android development. I guess
the big

items would be:

Android SDK and NDK are pre-installed (though may need to use
commands

to install other versions anyway)
A working emulator configuration is pre-installed through AVD

That's about it. If the build config doesn't match, you still need
to

re-configure the host. Deployment appears to be through normal
gradle

plugins, which would work for any build system.

The basic instructions for building android apps:
https://circleci.com/docs/android/
A description of how caching works:
https://circleci.com/docs/how-cache-works/

Hope this helps,

Brent

On Fri, Aug 26, 2016 at 7:46 AM, Yaw Anokwa yanokwa@nafundi.com wrote:

Thanks for looking into CircleCI, Brent. My gut says that we
should

try it first, if that ends up sucking, we can fallback switch to
Jenkins, warts and all. Do you have the cycles to give it a try
on the

Collect repo?

Yaw

On Thu, Aug 25, 2016 at 2:37 PM, Brent Atkinson brent.atkinson@gmail.com wrote:

Sorry for the noise, but reading more on CircleCI, they claim
that

they
allow you to do whatever you want on their environments. It
probably

still
means you're stuck with their starting environments, but it
seems

you at
least have full control over them.

Brent

On Thu, Aug 25, 2016 at 10:28 AM, Brent Atkinson brent.atkinson@gmail.com wrote:

Hi,

I have used Jenkins and Travis. I haven't used CircleCI, but it
seems
extremely similar in spirit to Travis (connect your GitHub
project

and go,
add YAML for customization).

In my experience, the biggest difference between Jenkins and
these

other
tools is that it is extremely flexible in terms of deployment.
You

can setup
a single master on your machine, a massive master/slave setup
in

the cloud,
or use as-a-service with something like CloudBees. My
experience

with CIaaS
is that it's a perfect free option for projects that fit well
within the
templates, but once you start needing more exotic
configurations

not being
able to fully control the environment makes them less
attractive.

Brent

On Wednesday, August 24, 2016 at 4:01:54 AM UTC-4, Yaw Anokwa wrote:

This is great info. Looks like Jenkins is what most are
using. My

light reading is that their Android integration isn't amazing.

Has anyone tried CircleCI? It visually looks better, has
reportedly
better Android support, and is free for OSS.

On Tue, Aug 23, 2016 at 10:53 PM, Matt Berg <mlb...@gmail.com wrote:

We use Jenkins and Drone. Jenkins I believe offers a free
service for
OS
projects if you are ok with waiting for your builds in a
queue.

Matt

On Aug 23, 2016 1:34 PM, "Jeffrey Beorse" jbe...@cs.washington.edu wrote:

Hi Yaw,

I'm not sure how familiar you are with what we're doing in
ODK

2.0,
but
we're using Jenkins to decent success. I'd echo Chris's
endorsement of
Jenkins on EC2.

Jenkins is pretty powerful and gives you a lot of control
over

the
details
of your build. There are vast amounts of plugins, including
integration with
Github, Gradle, Android Emulators, JaCoCo, etc. We're
running

custom
scripts
to handle copying file dependencies, automating
multi-emulator

test
suites,
controlling slave systems for UI tests, publishing binaries
through
Artifactory, graphing code coverage summaries, and more.
We're

running
automatic builds on each push to the development or demo
branches,
including
building signed APKs. We still build our master branch
release

binaries by
hand because we like to do some hand testing before the
real

release,
but we
could easily build them with Jenkins too.

Its not all perfect, of course. As Chris implied, Jenkins
can

be
pretty
finicky. With each version bump we seem to have to fix our
github
integration. Documentation can be spotty depending on the
plugin.
Emulators
misbehave, though this is probably more Google's fault.

I don't have any experience with Travis, so I can't
compare the

two
systems. All I can say is we've had an overall positive
experience
with
Jenkins.

Regards,
Jeff

On Tue, Aug 23, 2016 at 8:50 AM, Sam Sudar < suda...@gmail.com> wrote:

I've used Travis github integration in the past for a
small

project:

https://github.com/srsudar/odk-sms-bridge

You can see example build output here:

https://travis-ci.org/srsudar/odk-sms-bridge

I found it easy to work with. I believe I was building per
commit,
not
nightly. It isn't a complicated project, however, and I
don't

know
what
it's like setting it up for publishing the nightly builds
to a

location.

I have no experience building signed APKs automatically,
so I

can't
speak
to Chris's points about key locations or automatic
signing.

On Tue, Aug 23, 2016 at 5:37 AM, Christopher Robert cro...@surveycto.com wrote:

Hi Yaw,

We automate builds with Jenkins on AWS EC2. However, we
have

always
built our Android apk separately for a couple of reasons:

We wanted to more tightly control the build environment,
including
the
version of Java.
We wanted to guard the key we used to sign the apk
closely.

And we ran into trouble with the Android SDK on EC2
(something about
x64
EC2 environments).

For 3, there are blog posts like this one, AWS seems to
have

embraced
Jenkins, and with their mobile SDK AWS is clearly trying
to

accommodate
mobile developers. So I suspect that if we went back to
try

it
again,
everything would be fine.

As for 1 and 2, I think that those are less of a concern
now.

Back
in
2013 we were a bit less comfortable with our EC2/Linux
skills

and so
we
preferred building with Maven on OSX. But now I think
that we

could
have a
well-controlled environment on which we wouldn't mind
housing

our
private
key.

So, I'd recommend Jenkins on EC2 -- though I will say
that

it's not
uncommon for Jenkins to get OOM errors and need to be
restarted. We
keep
bumping up the memory on our dev server, but nothing
seems to

be
quite what
Jenkins wants. (I think that it wants a large memory swap
file, but
we don't
have a local drive on that machine and so don't have a
memory

swap
configured.)

Best,

Chris

On Tue, Aug 23, 2016 at 8:21 AM Yaw Anokwa yan...@nafundi.com wrote:

Hi all,

I'd like to get automated nightly builds for ODK
Collect and

I'd
love
to hear from folks who've used continuous integration
and

testing
on
Android apps.

I'm guessing the folks at Dimagi, Kobo, SurveyCTO, Ona,
and

ELMO
all
have some experience here. What platform did you use?
Would

you
recommend it?

Thanks,

Yaw

--
You received this message because you are subscribed to
the

Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails
from it,
send
an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/op
tout.

--
You received this message because you are subscribed to
the

Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails
from

it,
send
an email to
opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/op
tout.

--
You received this message because you are subscribed to
the

Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails
from

it,
send an
email to opendatakit-developers+unsubsc
ribe@googlegroups.com.

For more options, visit https://groups.google.com/d/op
tout.

--
You received this message because you are subscribed to the
Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails
from

it, send
an
email to opendatakit-developers+unsubsc
ribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout
.

--
You received this message because you are subscribed to the
Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails
from

it, send
an
email to opendatakit-developers+unsubsc
ribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it,

send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the
Google

Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from
it,

send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send

an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
If we keep uppermost in our minds the unkind and unjust acts of
others, we

shall find it impossible to love them as Christ has loved us; but if
our

thoughts dwell upon the wondrous love and pity of Christ for us, the
same

spirit will flow out to others.

--
You received this message because you are subscribed to the Google
Groups

"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it,
send an

email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google
Groups "ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups
"ODK Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to opendatakit-developers+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


(Yaw Anokwa) #19

Jeff and Sam, thanks for all your work on this! I've added you both to
the CircleCI team. Ping me off list if that isn't working for you.

Yaw

ยทยทยท On Thu, Sep 8, 2016 at 7:41 AM, Jeffrey Beorse wrote: > Sam is correct, the Gradle wrapper was out of date. It would fail even on > local command line builds (though of course not on Android Studio builds, as > Android Studio doesn't use the wrapper). I went ahead and updated the Gradle > wrapper. The process is exactly as Sam described: after installing Gradle on > your system, run 'gradle wrapper' at the root level of Collect. > > The repo is currently in the exact state that built for me with Circle CI. > If you turn it back on, I believe it should pass. > > Regards, > Jeff > > On Wed, Sep 7, 2016 at 8:55 AM, Sam Sudar wrote: >> >> I have no experience with Circle CI and no opinion on which we should >> choose. >> >> In case others are interested, however, I have a very thin repackaging of >> Collect that I set up with Travis integration this weekend. I chose Travis >> over Circle CI only because I'm more familiar with Travis. >> >> Github: https://github.com/srsudar/MamasDelRioAndroid/ >> Travis: https://travis-ci.org/srsudar/MamasDelRioAndroid >> >> It has Robolectric tests for the modules that I've added. It has Google >> Analytics integrated, which requires a google-services.json file to be >> present in the app directory. This is confidential and normally not >> versioned but is required for the build. I added it as an encrypted file, >> following these instructions. There were a few gotchas, but overall it was >> pretty painless. >> >> You can see the full build instructions in the travis.yaml file in the >> repo. It is based in part on Robolectric's travis.yaml. >> >> Sam >> >> On Wed, Sep 7, 2016 at 8:32 AM, Sam Sudar wrote: >>> >>> Yaw, >>> >>> I couldn't get past that error on the default Collect repo. I had to >>> regenerate the wrapper by running `gradle wrapper` from the base directory >>> of the project to recreate the wrapper. >>> >>> Sam >>> >>> On Wed, Sep 7, 2016 at 8:13 AM, Yaw Anokwa wrote: >>>> >>>> Hi Jeff, >>>> >>>> Forgive my ignorance, but when I point CircleCI at my Collect fork, it >>>> blows up with a NoClassDefFoundError: >>>> org/gradle/cli/CommandLineParser. The full trace is at >>>> http://dpaste.com/3E2GQQ0. >>>> >>>> Did you do any configuration in CircleCI to get it to build or was it >>>> really set it and forget? >>>> >>>> Thanks, >>>> >>>> Yaw >>>> -- >>>> Need ODK consultants? Nafundi provides form design, server setup, >>>> in-field training, and software development for ODK. Go to >>>> https://nafundi.com to get started. >>>> >>>> On Fri, Sep 2, 2016 at 3:53 AM, Jeffrey Beorse wrote: >>>> > Hi, >>>> > >>>> > I made a couple personal forks of Collect and tried both Travis and >>>> > Circle >>>> > CI just to see how they work, for fun. Below is my experience, but I >>>> > only >>>> > spent an hour or two with them, so take everything with some salt. >>>> > @Brent, >>>> > you should be able to fork Collect through the typical Github workflow >>>> > and >>>> > everything should work. You can also just pull Collect from >>>> > opendatakit's >>>> > github and push to an empty repo of your own. >>>> > >>>> > Between the two cloud CI options, I found Circle CI's Android support >>>> > to be >>>> > significantly smoother and easier to use. I believe Travis is still in >>>> > beta, >>>> > so this may improve, but as it stands now Circle CI is nicer in my >>>> > opinion. >>>> > With Circle CI I was able to sign up for an account, press go on my >>>> > Collect >>>> > fork, and have it successfully build. I didn't even need to push a yml >>>> > file >>>> > to my Github repo (though obviously we would need one for anything >>>> > more than >>>> > a proof of concept). With Travis I spent a lot of time fiddling with >>>> > my yml >>>> > and reading cryptic build failures when the equivalent Gradle commands >>>> > worked fine locally. I know Brent had issues with Circle CI missing an >>>> > Android API level, but you have to specify your API level in Travis >>>> > too, so >>>> > that doesn't like a win to me. I am not aware of any fundamental >>>> > differences >>>> > in their platforms, so more mature Android support seems as good a >>>> > reason as >>>> > any to pick Circle CI. >>>> > >>>> > Coming from a Jenkins background, they both felt very bare bones to >>>> > me. >>>> > Right away I wondered how we might run emulator tests on multiple >>>> > Android OS >>>> > versions (i.e. test on 4.3, 4.4, 5.0. 5.1, etc). What if we need >>>> > additional >>>> > scripting or build environment control? Brent addresses these types of >>>> > things in his third bullet point above. But Collect's code base, as it >>>> > is >>>> > today, doesn't have any tests and doesn't need a customized build >>>> > environment. So is it worth the effort to maintain a Jenkins server to >>>> > have >>>> > these options in the future? >>>> > >>>> > I agree with Brent's assessment above. Assuming we aren't afraid to >>>> > switch >>>> > to Jenkins down the road, my vote would be to choose the tool that >>>> > meets our >>>> > current needs with minimal effort and upgrade if a compelling reason >>>> > arises. >>>> > >>>> > I'd definitely encourage more people to try forking Collect and >>>> > experimenting for themselves. It turned out to be dead simple. I'm >>>> > interested to hear all of your experiences. I'm also happy to >>>> > contribute to >>>> > Brent's effort to make a comparable configuration if there is a list >>>> > of >>>> > features desired from the server. >>>> > >>>> > Regards, >>>> > Jeff >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > On Mon, Aug 29, 2016 at 9:19 AM, Daniel Kayiwa wrote: >>>> >> >>>> >> I have seen a few projects realising that they made a mistake trying >>>> >> to >>>> >> manage their own infrastructure servers, and hence having to go >>>> >> through the >>>> >> pain of switching. >>>> >> So basing on this experience, even if the resources are available, i >>>> >> would >>>> >> vote for starting simple, with CI-as-a-service like Travis or Circle, >>>> >> etc. >>>> >> Then switch, only if it turns out not to meet the actual needs. >>>> >> >>>> >> On Mon, Aug 29, 2016 at 6:59 PM, Brent Atkinson wrote: >>>> >>> >>>> >>> Hi Carl, >>>> >>> >>>> >>> Apologies for the delay responding. I don't know enough to say with >>>> >>> confidence which I would prefer at this point. I believe almost all >>>> >>> of these >>>> >>> could work since most CI software systems are doing very similar >>>> >>> things. My >>>> >>> sense is that it will boil down to whether we need/want full control >>>> >>> and >>>> >>> have the resources to commit or whether we need/want to use a freely >>>> >>> available service and don't need as much control. >>>> >>> >>>> >>> My inclination would be to use the CI-as-a-service tools unless it >>>> >>> just >>>> >>> won't work for what we want it for. It's less of a commitment from a >>>> >>> time/money perspective unless it just can't work for what we're >>>> >>> looking to >>>> >>> do. >>>> >>> >>>> >>> The types of questions I would want to answer to have confidence in >>>> >>> a >>>> >>> recommendation for ODK: >>>> >>> >>>> >>> Do we have resources to build and maintain and monitor a build farm >>>> >>> over >>>> >>> time? >>>> >>> >>>> >>> No: I would favor CI-as-a-service like Travis/Circle - no host >>>> >>> provisioning or maintenance, minimal or no cost >>>> >>> Yes: Full control over all aspects of setup using a free-as-in-beer >>>> >>> server like Jenkins is more attractive >>>> >>> >>>> >>> Are there parts of ODK that can not be made publicly available? >>>> >>> >>>> >>> No: CI-as-a-service like Travis/Circle are still an option >>>> >>> Yes: Private build farm might be necessary, though could still be >>>> >>> possible to use CI-as-a-service depending on the specifics (may >>>> >>> require more >>>> >>> $ or configuration to make it work) >>>> >>> >>>> >>> What level of maturity are we looking to achieve with the CI setup? >>>> >>> >>>> >>> Basic (basic builds on commit, test running/reporting): >>>> >>> CI-as-a-service >>>> >>> is often a better option due to low/no cost and and no host >>>> >>> maintenance >>>> >>> Intermediate (grid builds, additional analytics and trending): >>>> >>> Depending >>>> >>> on specifics could favor CI-as-a-service for turn key simplicity, or >>>> >>> private >>>> >>> setup for ease due to having full control over configuration and >>>> >>> deployment >>>> >>> Advanced (complicated build pipelines, custom plugins, exotic build >>>> >>> environments): Usually favor the private setup due to controlling >>>> >>> all >>>> >>> aspects of setup, however, pay options for the other tools are >>>> >>> available and >>>> >>> may be as good or better as freely available tools like Jenkins >>>> >>> >>>> >>> Do we need to handle secrets like API keys or signing certificates >>>> >>> as >>>> >>> part of the build process (or deployment if we're doing full >>>> >>> deployment >>>> >>> pipeline)? >>>> >>> >>>> >>> Yes: CI-as-a-service like Travis/Circle allow for encrypting >>>> >>> environment >>>> >>> variables and files so you can check them into projects and still >>>> >>> keep their >>>> >>> contents private. The simplicity of CI-as-a-service starts to fade a >>>> >>> bit >>>> >>> here. It may be easier/safer to run only on private servers >>>> >>> depending on >>>> >>> pain involved or level of paranoia. >>>> >>> No: CI-as-a-service can be far faster if the setup is directly >>>> >>> supported. This relates to what I was testing before, and >>>> >>> unfortunately, the >>>> >>> fact that the android API 19 wasn't installed already, meant I have >>>> >>> more >>>> >>> work to do to make CI-as-a-service work. This doesn't necessarily >>>> >>> make it >>>> >>> worse than a private setup though, since you have to >>>> >>> configure/provision >>>> >>> *everything* in that case. >>>> >>> >>>> >>> I'm sure there are other important details I am missing, but this >>>> >>> should >>>> >>> give you an idea of the types of things to consider and have clarity >>>> >>> on. At >>>> >>> this point, I still think it is worth seeing how far we can go with >>>> >>> a >>>> >>> CI-as-a-service setup unless we can identify a deal breaker and/or >>>> >>> self-hosting on a longer time scale isn't feasible for the project. >>>> >>> >>>> >>> If you all think it is worth while, I am willing to continue >>>> >>> attempting >>>> >>> to setup Collect to build on both Travis and Circle. It might be >>>> >>> possible >>>> >>> for me to fork Collect so I don't need special permissions and then >>>> >>> submit >>>> >>> the configs back as pull requests. Then you all could review them, >>>> >>> and >>>> >>> choose which to integrate, if any? >>>> >>> >>>> >>> Brent >>>> >>> >>>> >>> On Fri, Aug 26, 2016 at 7:33 PM, Carl Hartung wrote: >>>> >>>> >>>> >>>> Hey Brent, >>>> >>>> After your trial with CircleCI compared to your experience in >>>> >>>> Jenkins >>>> >>>> and Travis, do you find yourself having a preference for one? or >>>> >>>> think one >>>> >>>> would work better for Collect? >>>> >>>> >>>> >>>> It sounds like there's generally more experience amonst the >>>> >>>> community >>>> >>>> with Jenkins, so it might be easier to use/modify/troubleshoot if >>>> >>>> we go that >>>> >>>> route. >>>> >>>> -Carl >>>> >>>> >>>> >>>> >>>> >>>> On Fri, Aug 26, 2016 at 7:40 AM, Brent Atkinson wrote: >>>> >>>>> >>>> >>>>> Hi Yaw, >>>> >>>>> >>>> >>>>> Unfortunately, I can not do this with collect since I am not part >>>> >>>>> of >>>> >>>>> the github organization. >>>> >>>>> >>>> >>>>> However, I tried it with another android project. It did a good >>>> >>>>> job of >>>> >>>>> inferring the basic setup, but not enough to successfully build >>>> >>>>> the project. >>>> >>>>> It failed due to the android setup not being the version expected >>>> >>>>> for the >>>> >>>>> project. Looking into a resolution, it appears Circle is very >>>> >>>>> similar to >>>> >>>>> TravisCI. You have to specify additional specifications and/or >>>> >>>>> commands in a >>>> >>>>> special yaml file in the repository. Also, the host is configured >>>> >>>>> fresh from >>>> >>>>> a base image every time. Android SDK commands need to be run to >>>> >>>>> install >>>> >>>>> build tools or API before the build commands, which increases the >>>> >>>>> build >>>> >>>>> times considerably compared to a base image customized to the >>>> >>>>> application. >>>> >>>>> There are ways to ask CircleCI to cache certain directories, which >>>> >>>>> can limit >>>> >>>>> the effects of this. >>>> >>>>> >>>> >>>>> I think this would work, but I don't see anything specific to >>>> >>>>> CircleCI >>>> >>>>> that makes it better than others for android development. I guess >>>> >>>>> the big >>>> >>>>> items would be: >>>> >>>>> >>>> >>>>> Android SDK and NDK are pre-installed (though may need to use >>>> >>>>> commands >>>> >>>>> to install other versions anyway) >>>> >>>>> A working emulator configuration is pre-installed through AVD >>>> >>>>> >>>> >>>>> That's about it. If the build config doesn't match, you still need >>>> >>>>> to >>>> >>>>> re-configure the host. Deployment appears to be through normal >>>> >>>>> gradle >>>> >>>>> plugins, which would work for any build system. >>>> >>>>> >>>> >>>>> The basic instructions for building android apps: >>>> >>>>> https://circleci.com/docs/android/ >>>> >>>>> A description of how caching works: >>>> >>>>> https://circleci.com/docs/how-cache-works/ >>>> >>>>> >>>> >>>>> Hope this helps, >>>> >>>>> >>>> >>>>> Brent >>>> >>>>> >>>> >>>>> On Fri, Aug 26, 2016 at 7:46 AM, Yaw Anokwa wrote: >>>> >>>>>> >>>> >>>>>> Thanks for looking into CircleCI, Brent. My gut says that we >>>> >>>>>> should >>>> >>>>>> try it first, if that ends up sucking, we can fallback switch to >>>> >>>>>> Jenkins, warts and all. Do you have the cycles to give it a try >>>> >>>>>> on the >>>> >>>>>> Collect repo? >>>> >>>>>> >>>> >>>>>> Yaw >>>> >>>>>> >>>> >>>>>> On Thu, Aug 25, 2016 at 2:37 PM, Brent Atkinson wrote: >>>> >>>>>> > Sorry for the noise, but reading more on CircleCI, they claim >>>> >>>>>> > that >>>> >>>>>> > they >>>> >>>>>> > allow you to do whatever you want on their environments. It >>>> >>>>>> > probably >>>> >>>>>> > still >>>> >>>>>> > means you're stuck with their starting environments, but it >>>> >>>>>> > seems >>>> >>>>>> > you at >>>> >>>>>> > least have full control over them. >>>> >>>>>> > >>>> >>>>>> > Brent >>>> >>>>>> > >>>> >>>>>> > On Thu, Aug 25, 2016 at 10:28 AM, Brent Atkinson wrote: >>>> >>>>>> >> >>>> >>>>>> >> Hi, >>>> >>>>>> >> >>>> >>>>>> >> I have used Jenkins and Travis. I haven't used CircleCI, but >>>> >>>>>> >> it >>>> >>>>>> >> seems >>>> >>>>>> >> extremely similar in spirit to Travis (connect your GitHub >>>> >>>>>> >> project >>>> >>>>>> >> and go, >>>> >>>>>> >> add YAML for customization). >>>> >>>>>> >> >>>> >>>>>> >> In my experience, the biggest difference between Jenkins and >>>> >>>>>> >> these >>>> >>>>>> >> other >>>> >>>>>> >> tools is that it is extremely flexible in terms of deployment. >>>> >>>>>> >> You >>>> >>>>>> >> can setup >>>> >>>>>> >> a single master on your machine, a massive master/slave setup >>>> >>>>>> >> in >>>> >>>>>> >> the cloud, >>>> >>>>>> >> or use as-a-service with something like CloudBees. My >>>> >>>>>> >> experience >>>> >>>>>> >> with CIaaS >>>> >>>>>> >> is that it's a perfect free option for projects that fit well >>>> >>>>>> >> within the >>>> >>>>>> >> templates, but once you start needing more exotic >>>> >>>>>> >> configurations >>>> >>>>>> >> not being >>>> >>>>>> >> able to fully control the environment makes them less >>>> >>>>>> >> attractive. >>>> >>>>>> >> >>>> >>>>>> >> Brent >>>> >>>>>> >> >>>> >>>>>> >> >>>> >>>>>> >> >>>> >>>>>> >> On Wednesday, August 24, 2016 at 4:01:54 AM UTC-4, Yaw Anokwa wrote: >>>> >>>>>> >>> >>>> >>>>>> >>> This is great info. Looks like Jenkins is what most are >>>> >>>>>> >>> using. My >>>> >>>>>> >>> light reading is that their Android integration isn't >>>> >>>>>> >>> amazing. >>>> >>>>>> >>> >>>> >>>>>> >>> Has anyone tried CircleCI? It visually looks better, has >>>> >>>>>> >>> reportedly >>>> >>>>>> >>> better Android support, and is free for OSS. >>>> >>>>>> >>> >>>> >>>>>> >>> On Tue, Aug 23, 2016 at 10:53 PM, Matt Berg wrote: >>>> >>>>>> >>> > We use Jenkins and Drone. Jenkins I believe offers a free >>>> >>>>>> >>> > service for >>>> >>>>>> >>> > OS >>>> >>>>>> >>> > projects if you are ok with waiting for your builds in a >>>> >>>>>> >>> > queue. >>>> >>>>>> >>> > >>>> >>>>>> >>> > Matt >>>> >>>>>> >>> > >>>> >>>>>> >>> > >>>> >>>>>> >>> > On Aug 23, 2016 1:34 PM, "Jeffrey Beorse" wrote: >>>> >>>>>> >>> >> >>>> >>>>>> >>> >> Hi Yaw, >>>> >>>>>> >>> >> >>>> >>>>>> >>> >> I'm not sure how familiar you are with what we're doing in >>>> >>>>>> >>> >> ODK >>>> >>>>>> >>> >> 2.0, >>>> >>>>>> >>> >> but >>>> >>>>>> >>> >> we're using Jenkins to decent success. I'd echo Chris's >>>> >>>>>> >>> >> endorsement of >>>> >>>>>> >>> >> Jenkins on EC2. >>>> >>>>>> >>> >> >>>> >>>>>> >>> >> Jenkins is pretty powerful and gives you a lot of control >>>> >>>>>> >>> >> over >>>> >>>>>> >>> >> the >>>> >>>>>> >>> >> details >>>> >>>>>> >>> >> of your build. There are vast amounts of plugins, >>>> >>>>>> >>> >> including >>>> >>>>>> >>> >> integration with >>>> >>>>>> >>> >> Github, Gradle, Android Emulators, JaCoCo, etc. We're >>>> >>>>>> >>> >> running >>>> >>>>>> >>> >> custom >>>> >>>>>> >>> >> scripts >>>> >>>>>> >>> >> to handle copying file dependencies, automating >>>> >>>>>> >>> >> multi-emulator >>>> >>>>>> >>> >> test >>>> >>>>>> >>> >> suites, >>>> >>>>>> >>> >> controlling slave systems for UI tests, publishing >>>> >>>>>> >>> >> binaries >>>> >>>>>> >>> >> through >>>> >>>>>> >>> >> Artifactory, graphing code coverage summaries, and more. >>>> >>>>>> >>> >> We're >>>> >>>>>> >>> >> running >>>> >>>>>> >>> >> automatic builds on each push to the development or demo >>>> >>>>>> >>> >> branches, >>>> >>>>>> >>> >> including >>>> >>>>>> >>> >> building signed APKs. We still build our master branch >>>> >>>>>> >>> >> release >>>> >>>>>> >>> >> binaries by >>>> >>>>>> >>> >> hand because we like to do some hand testing before the >>>> >>>>>> >>> >> real >>>> >>>>>> >>> >> release, >>>> >>>>>> >>> >> but we >>>> >>>>>> >>> >> could easily build them with Jenkins too. >>>> >>>>>> >>> >> >>>> >>>>>> >>> >> Its not all perfect, of course. As Chris implied, Jenkins >>>> >>>>>> >>> >> can >>>> >>>>>> >>> >> be >>>> >>>>>> >>> >> pretty >>>> >>>>>> >>> >> finicky. With each version bump we seem to have to fix our >>>> >>>>>> >>> >> github >>>> >>>>>> >>> >> integration. Documentation can be spotty depending on the >>>> >>>>>> >>> >> plugin. >>>> >>>>>> >>> >> Emulators >>>> >>>>>> >>> >> misbehave, though this is probably more Google's fault. >>>> >>>>>> >>> >> >>>> >>>>>> >>> >> I don't have any experience with Travis, so I can't >>>> >>>>>> >>> >> compare the >>>> >>>>>> >>> >> two >>>> >>>>>> >>> >> systems. All I can say is we've had an overall positive >>>> >>>>>> >>> >> experience >>>> >>>>>> >>> >> with >>>> >>>>>> >>> >> Jenkins. >>>> >>>>>> >>> >> >>>> >>>>>> >>> >> Regards, >>>> >>>>>> >>> >> Jeff >>>> >>>>>> >>> >> >>>> >>>>>> >>> >> On Tue, Aug 23, 2016 at 8:50 AM, Sam Sudar wrote: >>>> >>>>>> >>> >>> >>>> >>>>>> >>> >>> I've used Travis github integration in the past for a >>>> >>>>>> >>> >>> small >>>> >>>>>> >>> >>> project: >>>> >>>>>> >>> >>> >>>> >>>>>> >>> >>> https://github.com/srsudar/odk-sms-bridge >>>> >>>>>> >>> >>> >>>> >>>>>> >>> >>> You can see example build output here: >>>> >>>>>> >>> >>> >>>> >>>>>> >>> >>> https://travis-ci.org/srsudar/odk-sms-bridge >>>> >>>>>> >>> >>> >>>> >>>>>> >>> >>> I found it easy to work with. I believe I was building >>>> >>>>>> >>> >>> per >>>> >>>>>> >>> >>> commit, >>>> >>>>>> >>> >>> not >>>> >>>>>> >>> >>> nightly. It isn't a complicated project, however, and I >>>> >>>>>> >>> >>> don't >>>> >>>>>> >>> >>> know >>>> >>>>>> >>> >>> what >>>> >>>>>> >>> >>> it's like setting it up for publishing the nightly builds >>>> >>>>>> >>> >>> to a >>>> >>>>>> >>> >>> location. >>>> >>>>>> >>> >>> >>>> >>>>>> >>> >>> I have no experience building signed APKs automatically, >>>> >>>>>> >>> >>> so I >>>> >>>>>> >>> >>> can't >>>> >>>>>> >>> >>> speak >>>> >>>>>> >>> >>> to Chris's points about key locations or automatic >>>> >>>>>> >>> >>> signing. >>>> >>>>>> >>> >>> >>>> >>>>>> >>> >>> On Tue, Aug 23, 2016 at 5:37 AM, Christopher Robert wrote: >>>> >>>>>> >>> >>>> >>>> >>>>>> >>> >>>> Hi Yaw, >>>> >>>>>> >>> >>>> >>>> >>>>>> >>> >>>> We automate builds with Jenkins on AWS EC2. However, we >>>> >>>>>> >>> >>>> have >>>> >>>>>> >>> >>>> always >>>> >>>>>> >>> >>>> built our Android apk separately for a couple of >>>> >>>>>> >>> >>>> reasons: >>>> >>>>>> >>> >>>> >>>> >>>>>> >>> >>>> We wanted to more tightly control the build environment, >>>> >>>>>> >>> >>>> including >>>> >>>>>> >>> >>>> the >>>> >>>>>> >>> >>>> version of Java. >>>> >>>>>> >>> >>>> We wanted to guard the key we used to sign the apk >>>> >>>>>> >>> >>>> closely. >>>> >>>>>> >>> >>>> And we ran into trouble with the Android SDK on EC2 >>>> >>>>>> >>> >>>> (something about >>>> >>>>>> >>> >>>> x64 >>>> >>>>>> >>> >>>> EC2 environments). >>>> >>>>>> >>> >>>> >>>> >>>>>> >>> >>>> For 3, there are blog posts like this one, AWS seems to >>>> >>>>>> >>> >>>> have >>>> >>>>>> >>> >>>> embraced >>>> >>>>>> >>> >>>> Jenkins, and with their mobile SDK AWS is clearly trying >>>> >>>>>> >>> >>>> to >>>> >>>>>> >>> >>>> accommodate >>>> >>>>>> >>> >>>> mobile developers. So I suspect that if we went back to >>>> >>>>>> >>> >>>> try >>>> >>>>>> >>> >>>> it >>>> >>>>>> >>> >>>> again, >>>> >>>>>> >>> >>>> everything would be fine. >>>> >>>>>> >>> >>>> >>>> >>>>>> >>> >>>> As for 1 and 2, I think that those are less of a concern >>>> >>>>>> >>> >>>> now. >>>> >>>>>> >>> >>>> Back >>>> >>>>>> >>> >>>> in >>>> >>>>>> >>> >>>> 2013 we were a bit less comfortable with our EC2/Linux >>>> >>>>>> >>> >>>> skills >>>> >>>>>> >>> >>>> and so >>>> >>>>>> >>> >>>> we >>>> >>>>>> >>> >>>> preferred building with Maven on OSX. But now I think >>>> >>>>>> >>> >>>> that we >>>> >>>>>> >>> >>>> could >>>> >>>>>> >>> >>>> have a >>>> >>>>>> >>> >>>> well-controlled environment on which we wouldn't mind >>>> >>>>>> >>> >>>> housing >>>> >>>>>> >>> >>>> our >>>> >>>>>> >>> >>>> private >>>> >>>>>> >>> >>>> key. >>>> >>>>>> >>> >>>> >>>> >>>>>> >>> >>>> So, I'd recommend Jenkins on EC2 -- though I will say >>>> >>>>>> >>> >>>> that >>>> >>>>>> >>> >>>> it's not >>>> >>>>>> >>> >>>> uncommon for Jenkins to get OOM errors and need to be >>>> >>>>>> >>> >>>> restarted. We >>>> >>>>>> >>> >>>> keep >>>> >>>>>> >>> >>>> bumping up the memory on our dev server, but nothing >>>> >>>>>> >>> >>>> seems to >>>> >>>>>> >>> >>>> be >>>> >>>>>> >>> >>>> quite what >>>> >>>>>> >>> >>>> Jenkins wants. (I think that it wants a large memory >>>> >>>>>> >>> >>>> swap >>>> >>>>>> >>> >>>> file, but >>>> >>>>>> >>> >>>> we don't >>>> >>>>>> >>> >>>> have a local drive on that machine and so don't have a >>>> >>>>>> >>> >>>> memory >>>> >>>>>> >>> >>>> swap >>>> >>>>>> >>> >>>> configured.) >>>> >>>>>> >>> >>>> >>>> >>>>>> >>> >>>> Best, >>>> >>>>>> >>> >>>> >>>> >>>>>> >>> >>>> Chris >>>> >>>>>> >>> >>>> >>>> >>>>>> >>> >>>> On Tue, Aug 23, 2016 at 8:21 AM Yaw Anokwa wrote: >>>> >>>>>> >>> >>>>> >>>> >>>>>> >>> >>>>> Hi all, >>>> >>>>>> >>> >>>>> >>>> >>>>>> >>> >>>>> I'd like to get automated nightly builds for ODK >>>> >>>>>> >>> >>>>> Collect and >>>> >>>>>> >>> >>>>> I'd >>>> >>>>>> >>> >>>>> love >>>> >>>>>> >>> >>>>> to hear from folks who've used continuous integration >>>> >>>>>> >>> >>>>> and >>>> >>>>>> >>> >>>>> testing >>>> >>>>>> >>> >>>>> on >>>> >>>>>> >>> >>>>> Android apps. >>>> >>>>>> >>> >>>>> >>>> >>>>>> >>> >>>>> I'm guessing the folks at Dimagi, Kobo, SurveyCTO, Ona, >>>> >>>>>> >>> >>>>> and >>>> >>>>>> >>> >>>>> ELMO >>>> >>>>>> >>> >>>>> all >>>> >>>>>> >>> >>>>> have some experience here. What platform did you use? >>>> >>>>>> >>> >>>>> Would >>>> >>>>>> >>> >>>>> you >>>> >>>>>> >>> >>>>> recommend it? >>>> >>>>>> >>> >>>>> >>>> >>>>>> >>> >>>>> Thanks, >>>> >>>>>> >>> >>>>> >>>> >>>>>> >>> >>>>> Yaw >>>> >>>>>> >>> >>>>> >>>> >>>>>> >>> >>>>> -- >>>> >>>>>> >>> >>>>> You received this message because you are subscribed to >>>> >>>>>> >>> >>>>> the >>>> >>>>>> >>> >>>>> Google >>>> >>>>>> >>> >>>>> Groups "ODK Developers" group. >>>> >>>>>> >>> >>>>> To unsubscribe from this group and stop receiving >>>> >>>>>> >>> >>>>> emails >>>> >>>>>> >>> >>>>> from it, >>>> >>>>>> >>> >>>>> send >>>> >>>>>> >>> >>>>> an email to >>>> >>>>>> >>> >>>>> opendatakit-developers+unsubscribe@googlegroups.com. >>>> >>>>>> >>> >>>>> For more options, visit >>>> >>>>>> >>> >>>>> https://groups.google.com/d/optout. >>>> >>>>>> >>> >>>> >>>> >>>>>> >>> >>>> -- >>>> >>>>>> >>> >>>> You received this message because you are subscribed to >>>> >>>>>> >>> >>>> the >>>> >>>>>> >>> >>>> Google >>>> >>>>>> >>> >>>> Groups "ODK Developers" group. >>>> >>>>>> >>> >>>> To unsubscribe from this group and stop receiving emails >>>> >>>>>> >>> >>>> from >>>> >>>>>> >>> >>>> it, >>>> >>>>>> >>> >>>> send >>>> >>>>>> >>> >>>> an email to >>>> >>>>>> >>> >>>> opendatakit-developers+unsubscribe@googlegroups.com. >>>> >>>>>> >>> >>>> For more options, visit >>>> >>>>>> >>> >>>> https://groups.google.com/d/optout. >>>> >>>>>> >>> >>> >>>> >>>>>> >>> >>> >>>> >>>>>> >>> >>> -- >>>> >>>>>> >>> >>> You received this message because you are subscribed to >>>> >>>>>> >>> >>> the >>>> >>>>>> >>> >>> Google >>>> >>>>>> >>> >>> Groups >>>> >>>>>> >>> >>> "ODK Developers" group. >>>> >>>>>> >>> >>> To unsubscribe from this group and stop receiving emails >>>> >>>>>> >>> >>> from >>>> >>>>>> >>> >>> it, >>>> >>>>>> >>> >>> send an >>>> >>>>>> >>> >>> email to >>>> >>>>>> >>> >>> opendatakit-developers+unsubscribe@googlegroups.com. >>>> >>>>>> >>> >>> For more options, visit >>>> >>>>>> >>> >>> https://groups.google.com/d/optout. >>>> >>>>>> >>> >> >>>> >>>>>> >>> >> >>>> >>>>>> >>> >> -- >>>> >>>>>> >>> >> You received this message because you are subscribed to >>>> >>>>>> >>> >> the >>>> >>>>>> >>> >> Google >>>> >>>>>> >>> >> Groups >>>> >>>>>> >>> >> "ODK Developers" group. >>>> >>>>>> >>> >> To unsubscribe from this group and stop receiving emails >>>> >>>>>> >>> >> from >>>> >>>>>> >>> >> it, send >>>> >>>>>> >>> >> an >>>> >>>>>> >>> >> email to >>>> >>>>>> >>> >> opendatakit-developers+unsubscribe@googlegroups.com. >>>> >>>>>> >>> >> For more options, visit >>>> >>>>>> >>> >> https://groups.google.com/d/optout. >>>> >>>>>> >>> > >>>> >>>>>> >>> > -- >>>> >>>>>> >>> > You received this message because you are subscribed to the >>>> >>>>>> >>> > Google >>>> >>>>>> >>> > Groups >>>> >>>>>> >>> > "ODK Developers" group. >>>> >>>>>> >>> > To unsubscribe from this group and stop receiving emails >>>> >>>>>> >>> > from >>>> >>>>>> >>> > it, send >>>> >>>>>> >>> > an >>>> >>>>>> >>> > email to >>>> >>>>>> >>> > opendatakit-developers+unsubscribe@googlegroups.com. >>>> >>>>>> >>> > For more options, visit https://groups.google.com/d/optout. >>>> >>>>>> >> >>>> >>>>>> >> -- >>>> >>>>>> >> You received this message because you are subscribed to the >>>> >>>>>> >> Google >>>> >>>>>> >> Groups >>>> >>>>>> >> "ODK Developers" group. >>>> >>>>>> >> To unsubscribe from this group and stop receiving emails from >>>> >>>>>> >> it, >>>> >>>>>> >> send an >>>> >>>>>> >> email to opendatakit-developers+unsubscribe@googlegroups.com. >>>> >>>>>> >> For more options, visit https://groups.google.com/d/optout. >>>> >>>>>> > >>>> >>>>>> > >>>> >>>>>> > -- >>>> >>>>>> > You received this message because you are subscribed to the >>>> >>>>>> > Google >>>> >>>>>> > Groups >>>> >>>>>> > "ODK Developers" group. >>>> >>>>>> > To unsubscribe from this group and stop receiving emails from >>>> >>>>>> > it, >>>> >>>>>> > send an >>>> >>>>>> > email to opendatakit-developers+unsubscribe@googlegroups.com. >>>> >>>>>> > For more options, visit https://groups.google.com/d/optout. >>>> >>>>>> >>>> >>>>>> -- >>>> >>>>>> You received this message because you are subscribed to the >>>> >>>>>> Google >>>> >>>>>> Groups "ODK Developers" group. >>>> >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>> >>>>>> send >>>> >>>>>> an email to opendatakit-developers+unsubscribe@googlegroups.com. >>>> >>>>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>>> >>>> >>>>> >>>> >>>>> -- >>>> >>>>> You received this message because you are subscribed to the Google >>>> >>>>> Groups "ODK Developers" group. >>>> >>>>> To unsubscribe from this group and stop receiving emails from it, >>>> >>>>> send >>>> >>>>> an email to opendatakit-developers+unsubscribe@googlegroups.com. >>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> You received this message because you are subscribed to the Google >>>> >>>> Groups "ODK Developers" group. >>>> >>>> To unsubscribe from this group and stop receiving emails from it, >>>> >>>> send >>>> >>>> an email to opendatakit-developers+unsubscribe@googlegroups.com. >>>> >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>>> >>> >>>> >>> -- >>>> >>> You received this message because you are subscribed to the Google >>>> >>> Groups >>>> >>> "ODK Developers" group. >>>> >>> To unsubscribe from this group and stop receiving emails from it, >>>> >>> send an >>>> >>> email to opendatakit-developers+unsubscribe@googlegroups.com. >>>> >>> For more options, visit https://groups.google.com/d/optout. >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> If we keep uppermost in our minds the unkind and unjust acts of >>>> >> others, we >>>> >> shall find it impossible to love them as Christ has loved us; but if >>>> >> our >>>> >> thoughts dwell upon the wondrous love and pity of Christ for us, the >>>> >> same >>>> >> spirit will flow out to others. >>>> >> >>>> >> -- >>>> >> You received this message because you are subscribed to the Google >>>> >> Groups >>>> >> "ODK Developers" group. >>>> >> To unsubscribe from this group and stop receiving emails from it, >>>> >> send an >>>> >> email to opendatakit-developers+unsubscribe@googlegroups.com. >>>> >> For more options, visit https://groups.google.com/d/optout. >>>> > >>>> > >>>> > -- >>>> > You received this message because you are subscribed to the Google >>>> > Groups >>>> > "ODK Developers" group. >>>> > To unsubscribe from this group and stop receiving emails from it, send >>>> > an >>>> > email to opendatakit-developers+unsubscribe@googlegroups.com. >>>> > For more options, visit https://groups.google.com/d/optout. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "ODK Developers" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to opendatakit-developers+unsubscribe@googlegroups.com. >>>> For more options, visit https://groups.google.com/d/optout. >>> >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "ODK Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to opendatakit-developers+unsubscribe@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "ODK Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to opendatakit-developers+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout.

(John Shisoka) #20

Brent Atkinson, how are you ? i need to learn more about this