In the Open Event Android app we were using Travis already to push an apk of the Android app to the apk branch for easy testing after each commit in the repo. A better way to test the dynamic nature of the app would be to use the samples of different events from the Open Event repo to generate an apk for each sample. This could help us identify bugs and inconsistencies in the generator and the Android app easily. In this blog I will be talking about how this was implemented using Travis CI.
What is a CI?
Continuous Integration is a DevOps software development practice where developers regularly push their code changes into a central repository. After the merge automated builds and tests are run on the code that has been pushed. This helps developers to identify bugs in code quite easily. There are many CI’s available such as Travis, Codecov etc.
Now that we are all caught up with let’s dive into the code.
Script for replacing a line in a file (configedit.sh)
The main role of this script would be to replace a line in the config.json file. Why do we need this? This would be used to reconfigure the Api_Link in the config.json file according to our build parameters. If we want the apk for Mozilla All Hands 2017 to be built, I would use this script to replace the Api_Link in the config.json file to the one for Mozilla All Hands 2017.
This is what the config.json file for the app looks like.
{
"Email": "dev@fossasia.org",
"App_Name": "Open Event",
"Api_Link": "https://eventyay.com/api/v1/events/6/"
}
We are going to replace line 4 of this file with
“Api_Link”:”https://raw.githubusercontent.com/fossasia/open-event/master/sample/MozillaAllHands17“
VAR=0 STRING1=$1 while read line do ((VAR+=1)) if [ "$VAR" = 4 ]; then echo "$STRING1" else echo "$line" fi done < app/src/main/assets/config.json
The script above reads the file line by line. If it reaches line 4 it would print out the string that was given into the script as a parameter else it just prints out the line in the file.
This script would print the required file for us in the terminal if called but NOT create the required file. So we redirect the output of this file into the same file config.json.
Now let’s move on to the main script which is responsible for the building of the apks.
Build Script(generate_apks.sh)
Main components of the script
- Build the apk for the default sample i.e FOSSASIA17 using the build scripts ./gradlew build and ./gradlew assembleRelease.
- Store all the Api_Links and apk names for which we need the apks for different arrays
- Replace the Api_Link in the json file found under android/app/src/main/assets/config.json using the configedit.sh.
- Run the build scripts ./gradlew build and ./gradlew assembleRelease to generate the apk.
- Move the generated apk from app/build/outputs/apk/ to a folder called daily where we store all the generated apks.
- We then repeat this process for the other Api_Links in the array.
As of now we are generating the apks for the following events:
- FOSSASIA 17
- Mozilla All Hands 17
- Google I/O 17
- Facebook Developer Conference 17
Care is also taken to avoid all these builds if it is a PR. All the apks are generated only when there is a commit on the development branch i.e when the PR is merged.
Usage of Scripts in .travis.yml
To add Travis integration for the repo we need to include a file named .travis.yml in the repo which indicates Travis CI what to build.
language: android …. jdk: oraclejdk8 …. before_script: - cd android script: - chmod +x generate_apks.sh - chmod +x configedit.sh - ./generate_apks.sh ….. after_success: - bash <(curl -s https://codecov.io/bash) - cd .. - chmod +x upload-apk.sh - ./upload-apk.sh
In this file we need to define the language for which Travis will build. Here we indicate that it is android. We also specify the jdk version to be used.
Now let’s talk about the other parts of this snippet.
- before_script : Executes the bash instructions before the travis build starts. Here we do cd android so that we can access gradlew for building the apk.
- script : This section consists of the instruction to be executed for the build. Here we give executable rights to the two scripts that we have written sh and . Then ./generate_apks is called and the project build starts. All the apks get saved to the folder daily.
- after_success : This section consists the instructions that are run after the script executes successfully. Here we see that we run a script called sh. This script is responsible of pushing the generated apk files in an orphan branch called apk.
Some points of Interest
- If the user/developer testing the apk is in the offline state and then comes online there will be database inconsistencies as data from the local assets as well as the data from the Api_Link would appear in the app.
- When the app generator CLI is ready we can use it to trigger the builds instead of just replacing the Api_Link. This would also be effective in testing the app generator simultaneously.
Now we have everything setup to trigger builds for various samples after each commit.
Resources
- Travis CI Docs: https://docs.travis-ci.com/
- Bash scripting tutorial: http://ryanstutorials.net/bash-scripting-tutorial/
- Gradle Wrapper gradlew: https://docs.gradle.org/3.3/userguide/gradle_wrapper.html
- Continuous Integration: http://searchsoftwarequality.techtarget.com/definition/continuous-integration