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
Hi Yaw,
We automate builds with Jenkins on AWS EC2. However, we have always built
our Android apk separately for a couple of reasons:
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
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.
I've used Travis github integration in the past for a small project:
You can see example build output here:
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.
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
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.
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
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:
- 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
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.
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
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,
JeffOn 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:
- 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
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.
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.
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
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
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,
JeffOn 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.
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
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:
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:
Hope this helps,
Brent
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,
JeffOn 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
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.
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
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,
JeffOn 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
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
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.
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:
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
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.
-CarlOn 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,
JeffOn 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
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
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
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.
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.
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.
-CarlOn 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,
JeffOn 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
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
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
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
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.
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
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.
-CarlOn 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,
JeffOn 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
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
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
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
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
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.
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
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,
JeffOn 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 attractiveAre 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 JenkinsDo 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.
-CarlOn 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 AVDThat'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,
JeffOn 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
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
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
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
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
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.
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
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,
JeffOn 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 attractiveAre 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 JenkinsDo 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.
-CarlOn 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 AVDThat'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,
JeffOn 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
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
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
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
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
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
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.
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
Yaw,
I couldn't get past that error on the default Collect repo. I had to
regenerate the wrapper by runninggradle wrapperfrom 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,
JeffOn 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 attractiveAre 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 JenkinsDo 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.
-CarlOn 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 AVDThat'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,
JeffOn 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
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
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
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
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
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
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
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 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
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/MamasDelRioAndroidIt 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 runninggradle wrapperfrom 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,
JeffOn 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 attractiveAre 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 JenkinsDo 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.
-CarlOn 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 AVDThat'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,
JeffOn 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
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
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
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
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
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
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
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.
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
Brent Atkinson, how are you ? i need to learn more about this