content

In this article we will learn about CircleCI version 2.0, the meaning of the basic components in CircleCI’s configuration file.

Also, configure a basic project on Github to automatically build when the source code changes, combine with the Firebase Test Lab to perform tests and send analysis results back.

1. Introduction about CircleCI

CircleCI (Continuous integration) is a system that helps build applications automatically, perform testing and application deployment. Whenever your code changes on Github or Bitbucket, the system will automatically build the application and send an email to notify the success or failure to help developers quickly know the status of the application to promptly make necessary changes and repairs.

CircleCI works on all existing operating system platforms: Linux, Windows and MacOS. It can also be configured to deploy code on diverse environments such as AWS CodeDeploy, AWS EC2, AWS S3, Google Kubernetes Engine (GKE), Microsoft Azure, Heroku.

2. The basic key components in config.yml

To configure CircleCI from the source code of the application, in the main directory of the application we create a directory called .circleci , inside the directory we create a config.yml file

This file will usually have the following content

Looking from a sample config.yml file above, usually we will see a configuration file containing 4 main keys:

• version: this is the tag to declare the version of CircleCI that we will use to run, usually its value will be 2 corresponding to CircleCI version 2.0
• references: this is the tag we use to define constants, the references are used many times in this config file so that we don’t have to declare it over and over and make the config.yml file shorter. Usually we will declare the definition of variables to cache, workspace path and key from google, firebase …
• jobs: this is the place to show and define the most detailed work to be done, each job will be a set of steps necessary for building, testing or deploying of the project.
• workflows : is a set of rules to determine the set of jobs and their order of running. For example, if you define a set of sub-tasks to run during the build process, you tell CircleCI the dependencies between these tasks and it will run the independent tasks in parallel when it has enough information or satisfies one. certain conditions are pre-defined. Note that in order to run in parallel, the hardware configuration you register from CircleCI supports multitasking, usually paid packages will have multitasking.

3. Analyze the steps in a basic task build

Next we will go into analyzing a basic task build in a job to better understand the components in it. We define a job named build_debug that will have the following job tasks:

• working_directory: to define the directory name of our project on CircleCI, where our code will be clone from Github / Bitbucket.
• docker : is where we declare the image used for our project build. CircleCI and the community have built a set of built-in tools, libraries, and statements for each type of language project, making configuring CircleCI simpler. We just need to go to https://hub.docker.com/search/?q=circleci&type=image to search for images by project type and use.
• environment: is the place to set the environment requirements for the build. For example, using dum to avoid strange outputs from Gradle, limit the heap size of the JVM virtual machine to a maximum of 3Gb to avoid over-use of memory causing overflow and failure of the build process.
• steps: define a set of steps to build the project, as in the example above we will see there are steps:
  • checkout : this command helps checkout the project from Github or Bitbucket
  • restorecache : to restore the available configuration to reduce build time
  • ./gradlew androidDependencies : helps download libraries implemented in the project, if already stored in restore_cache, it only downloads libraries not in the cache, reducing build time.
  • savecache : re-cache to reuse for the next call
  • ./gradlew -PciBuild = true: app: assembleDebug: app: assembleAndroidTest : the command that helps build apk debug and apk for running instrumented tests.
  • store_artifacts : specifies where to store apk in CircleCI artifacts.

4. Linking and configuring projects with CircleCI

In the above steps we have learned how to create and add config.yml file into the project we need to set up CircleCI. In this step we will link our project on CircleCI page and make the necessary configuration on this page.

We access the page https://circleci.com/vcs-authorize/ choose where to store the project is GitHub or Bitbucket

Then we will be redirected to the configuration page of CircleCI, at tab “ADD PROJECTS” we will see a list of existing projects.

Select the project and click the “Set Up Project” button to go to the next step.

We select the operating system to build and the type of language, here is the Android project so we will choose Gradle (Java) .

Once setup is complete click the ” Start building ” button to start the system building our project, the results will be listed as shown below.

From the message FAILED or SUCCESS we can know whether the build process has succeeded or not. At the same time, you can click on the messages to see the details of the build process, if the build process fails we can observe which steps are wrong and make timely repairs.

Here I have introduced you the basic steps to configure CircleCI 2.0 for Android projects.

The next section will introduce configuration steps on Firebase Test Lab to link with CircleCI.

Refer

1. https://circleci.com/docs/2.0/language-android/