Some notes on exploring CI using Travis-ci for the Android app.

[julianharty]

Over the last month I've spent several days experimenting and learning from using travis-ci to build the Android codebase using a fork of the main eduVPN Android codbase. I'll write up various notes here so that I and anyone else interested can learn from my experiences. I hope we will also be able to improve the process and ultimately the software we're creating so users of the VPN software have high-quality and trustworthy network connections.

[julianharty]

First thing: travis-ci is available free-of-charge for public codebases such as ours. It includes support for much of our toolchain including building Android apps using Gradle https://guides.gradle.org/executing-gradle-builds-on-travisci/

However, they only support a very old release of Ubuntu trusty https://docs.travis-ci.com/user/languages/android/ and even if we specify a newer release I notice they actually use trusty. This choice affects at least 2 key aspects of the build:

1. The version of swig they run is archaic (2.0.11) and too old to use when building the native code used in sub-projects used by our Android app.
2. They install lots of obscelete Android components which extends the build time further.

We currently clone and build the current release of swig as part of the travis build process by adopting the same approach as AMICI-dev/AMICI#841 as an interim step to enable the Android build to complete successfully according to Gradle. In turn their approach may well be based on the one documented by travis-ci https://docs.travis-ci.com/user/installing-dependencies/ on building dependencies from source.

I'm tracking the build time at commercetest/android#3 and it's available for builds of my fork of the Android project at https://travis-ci.com/commercetest/android

[julianharty]

I experienced various challenges building the code in Android Studio (see eduvpn/android#201) and using gradle directly (see Inconsistent gradle builds. Some of this was related to the need to correctly clone nested sub-projects. As travis-ci does not seem to automatically clone sub-projects I configured the .travis.yml file to disable the default behaviour and run an explicit, recursive clone of subprojects.

Below is a snapshot of the .travis.yml file. Note this one happens to be configured to run the tests rather than building the app...

language: android
dist: xenial

git:
  submodules: false

android:
  components:
    - build-tools-29.0.2
    - android-29

before_install:
  - sudo apt-get update
  - sudo apt-get -y install ninja-build

install:
  - ./scripts/build_and_install_swig.sh
  - export PATH=$PATH:/home/travis/build/commercetest/android/ThirdParty/swig-4.0.1/install/bin
  - swig -version
  - echo y | sdkmanager "ndk-bundle"

before_script:
  - export ANDROID_NDK_HOME=$ANDROID_HOME/ndk-bundle
script:
  - git submodule update --init --recursive
  - ./gradlew test

and the request to use xenial is ignored by travis as confirmed in:

Distributor ID:	Ubuntu
Description:	Ubuntu 14.04.5 LTS
Release:	14.04
Codename:	trusty

https://travis-ci.com/commercetest/android/builds/138630008 and expand the Build system information to see the details of what's being used.

[julianharty]

There's a really helpful article on working effectively with travis-ci at https://eng.localytics.com/best-practices-and-common-mistakes-with-travis-ci/ e.g. on the troubleshooting tip to use a suitable docker image for testing build failures locally.