Blog Engineering Working with YAML in GitLab CI from the Android perspective
November 20, 2017
8 min read

Working with YAML in GitLab CI from the Android perspective

Guest author Renato Stanic shares a sample YAML configuration for Android projects, which helps his team with faster, more iterative development.

yaml-gitlab-ci-android.png

Using continuous integration in our everyday workflow can help us a lot with faster and iterative development, and having CI do checks every time we change our codebase helps us with deal with fear of modifying code.

Deploying app builds manually takes time and leaves us idle while we could be developing new and exciting features instead. Here at Undabot we are using GitLab CI for continuous integration. GitLab CI uses a YAML file for job configuration. In this blog post we will go through a sample YAML configuration for Android projects and describe the main YAML building blocks with common Android CI jobs.

YAML intro

The YAML file defines a set of jobs with constraints stating when they should be run. The jobs are defined as top-level elements with a name and always have to contain at least the script clause:

helloworld_job:
  script: "echo Hello World!"

assemble_job:
  script: "./gradlew assembleRelease"

YAML syntax allows for more complex job definitions than in the above example:

before_script:
  - bundle install

after_script:
  - rm secrets

stages:
  - build
  - test
  - deploy

helloworld_job:
  stage: build
  script:
    - echo Hello World
  only:
    - master
  tags:
    - android

before_script – commands that run before each jobs script
after_script – commands that run after each jobs script
stages – used to define build stages
only – defines the names of branches and tags for which the job will run
tags – used to select specific Runners from the list of all Runners that are allowed to run this project.

Initial setup for Android

First step is to create a YAML file called gitlab-ci.yml in root directory of your Android project and add the following code:

before_script:
  - export ANDROID_HOME="$HOME/Library/Android/sdk"
  - bundle install
stages:
  - build  
  - test
  - quality_assurance
  - deploy

In before_script we execute these two commands:
- export ANDROID_HOME="$HOME/Library/Android/sdk”– sets Android home environment variable to be available for all other jobs and Gradle tasks
- bundle install – we are using fastlane for task automation and Bundler to manage Ruby gems so we need to run bundle install to make sure everything is installed correctly.

In the stages section we define four build stages:
- build– for build jobs
- test– for test jobs that include unit and instrumentation tests
- quality_assurance– for jobs that run all of our QA tools
- deploy– for deployment jobs

Build stage

This job (build_job) is used to create an APK artifact that can be used to test the app manually or to upload it to the Play Store.

build_job:
  stage: build
  script:
    - ./gradlew clean assembleRelease
  artifacts:
    paths:
      - app/build/outputs/

build_job:– name of the CI job
stage: build– it gets executed in the build stage
./gradlew clean assembleRelease– executes Gradle command to create a release APK
artifacts:– job section that defines list of files and directories that are attached to a job after completion.
paths:– output file paths
app/build/outputs– directory path of our APK

Unit tests

This job (unit_tests) runs our unit tests in a test stage. Every time they fail, a report artifact will be created. Each report artifact expires within four days of creation.

unit_tests:
  stage: test
  script:
    - ./gradlew test
  artifacts:
    name: "reports_${CI_PROJECT_NAME}_${CI_BUILD_REF_NAME}"
    when: on_failure
    expire_in: 4 days
    paths:
      - app/build/reports/tests/

./gradlew test– run Gradle command that triggers our unit tests artifacts:
name:– defines artifact name by using environment variables
CI_PROJECT_NAME– project name that is currently being built
CI_BUILD_REF_NAME– branch or tag name for which project is built
when:– defines when is it created (on_success, on_failure, always)
expire_in:– defines when is it expired, after artifact has expired it gets deleted from CI

Instrumentation tests

This job (instrumentation_tests) runs all of our instrumentation tests in a test stage by starting a windowless emulator without sound and animations followed by a custom bash script that waits for the emulator to start, after which the device is unlocked by sending key event 82. When the emulator is ready we run the Gradle command for instrumentation tests. Once all tests finished running, the emulator is killed with a custom bash script.

instrumentation_tests:
  stage: test
  script:
    - emulator -avd testAVD -no-audio -no-window &
    - ./ci/android-wait-for-emulator.sh
    - adb devices
    - adb shell settings put global window_animation_scale 0 &
    - adb shell settings put global transition_animation_scale 0 &
    - adb shell settings put global animator_duration_scale 0 &
    - adb shell input keyevent 82 &
    - ./gradlew connectedAndroidTest
    - ./ci/stop-emulators.sh
  artifacts:
    name: "reports_${CI_PROJECT_NAME}_${CI_BUILD_REF_NAME}"
    when: on_failure
    expire_in: 4 days
    paths:
      - app/build/reports/androidTests/connected/

- emulator — avd testAVD -no-audio -no-window &
- ./ci/android-wait-for-emulator.sh
Starts the emulator and waits for it to boot.
- adb devices
Displays list of found devices in GitLab web terminal.
- adb shell settings put global window_animation_scale 0 &
- adb shell settings put global transition_animation_scale 0 &
- abd shell settings put global animator_duration_scale 0 &
Disables all animations and transitions.

Static analysis

This job (static_analysis) runs all of static code analysis in QA stage. This is a tricky area especially if you are working on a project with a lot of legacy code. My suggestion would be to disable all of the rules and start fixing them one at the time. Tools used for static analysis are lint, checkstyle, pmd and findbugs.

static_analysis:
  stage: quality_assurance
  script:
    - ./gradlew lint
    - ./gradlew checkstyle
    - ./gradlew pmd
    - ./gradlew findbugs
  artifacts:
    name: "reports_${CI_PROJECT_NAME}_${CI_BUILD_REF_NAME}"
    when: on_failure
    expire_in: 4 days
    paths:
      - app/build/reports/

- ./gradlew lint
- ./gradlew checkstyle
- ./gradlew pmd
- ./gradlew findbugs
Gradle commands that trigger QA tools.
- app/build/reports – path to our QA reports

Deploy stage

The final job (deploy_internal) deploys the app to the QA team in deploy stage. You don’t want to deploy every time you commit something so this step is set as manual. Manual jobs are triggered via GitLab web interface by pressing the play button in your pipeline list. If you are using fastlane as your deployment tool, the last job will look like the following code:

deploy_internal:
  stage: deploy
  script:
    - bundle exec fastlane android deploy_lane
  when: manual

- bundle exec fastlane android deploy_lane– executes fastlane deploy lane that deploys app to the QA team
when: manual – defines when is a job executed

There’s plenty more

Setting up Android continuous integration with GitLab CI is great and supports plenty of cool features a lot more than we showed. Hopefully this short introduction was helpful and is going to motivate you to discover more features on your own.

Complete gitlab-ci.yml:

before_script:
  - export ANDROID_HOME="$HOME/Library/Android/sdk"
  - bundle install

stages:
- build
- test
- quality_assurance
- deploy

build_job:
  stage: build
  script:
    - ./gradlew clean assembleRelease
  artifacts:
    paths:
    - app/build/outputs/

unit_tests:
  stage: test
  script:
    - ./gradlew test
  artifacts:
    name: "reports_${CI_PROJECT_NAME}_${CI_BUILD_REF_NAME}"
    when: on_failure
    expire_in: 4 days
    paths:
      - app/build/reports/tests/

instrumentation_tests:
  stage: test
  script:
    - emulator -avd testAVD -no-audio -no-window &
    - ./ci/android-wait-for-emulator.sh
    - adb devices
    - adb shell settings put global window_animation_scale 0 &
    - adb shell settings put global transition_animation_scale 0 &
    - adb shell settings put global animator_duration_scale 0 &
    - adb shell input keyevent 82 &
    - ./gradlew connectedAndroidTest
    - ./ci/stop-emulators.sh
  artifacts:
    name: "reports_${CI_PROJECT_NAME}_${CI_BUILD_REF_NAME}"
    when: on_failure
    expire_in: 4 days
    paths:
      - app/build/reports/androidTests/connected/

static_analysis:
  stage: quality_assurance
  script:
    - ./gradlew lint
    - ./gradlew checkstyle
    - ./gradlew pmd
    - ./gradlew findbugs
  artifacts:
    name: "reports_${CI_PROJECT_NAME}_${CI_BUILD_REF_NAME}"
    when: on_failure
    expire_in: 4 days
    paths:
      - app/build/reports/

deploy_internal:
  stage: deploy
  script:
    - bundle exec fastlane android deploy_lane
  when: manual

Working with YAML in GitLab CI from an Android perspective was originally published on Undabot's blog.

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

New to GitLab and not sure where to start?

Get started guide

Learn about what GitLab can do for your team

Talk to an expert