Using Jenkins to Create a Pipeline for Android Applications
This article is a tutorial on how to create a pipeline to perform code analysis using lint and create a APK file for Android applications.
Continuous integration is a practice that requires developers to integrate code into a shared repository such as GitHub, GitLab, SVN, etc, at regular intervals. This concept was meant to avoid the hassle of later finding problems in the build life cycle. Continuous integration requires developers to have frequent builds. The common practice is that whenever a code commit occurs, a build should be triggered. However, sometimes the build process is also scheduled in a way that too many builds are avoided. Jenkins is one of the most popular continuous integration tools.
Jenkins was known as a continuous integration server earlier. However, the Jenkins 2.0 announcement made it clear that, going forward, the focus would not only be on continuous integration but on continuous delivery too. Hence, ‘automation server’ is the term used more often after Jenkins 2.0 was released. It was initially developed by Kohsuke Kawaguchi in 2004, and is an automation server that helps to speed up different DevOps implementation practices such as continuous integration, continuous testing, continuous delivery, continuous deployment, continuous notifications, orchestration using a build pipeline or Pipeline as a Code.
Jenkins helps to manage different application lifecycle management activities. Users can map continuous integration with build, unit test execution and static code analysis; continuous testing with functional testing, load testing and security testing; continuous delivery and deployment with automated deployment into different environments, and so on. Jenkins provides easier ways to configure DevOps practices. The Jenkins package has two release lines:
LTS (long term support): Releases are selected every 12 weeks from the stream of regular releases, ensuring a stable release.
Weekly: A new release is available every week to fix bugs and provide features to the community.
LTS and weekly releases are available in different flavours such as .war files (Jenkins is written in Java), native packages for the operating systems, installers and Docker containers.
The current LTS version is Jenkins 2.73.3. This version comes with a very useful option, called Deploy to Azure. Yes, we can deploy Jenkins to the Microsoft Azure public cloud within minutes. Of course, you need a Microsoft Azure subscription to utilise this option. Jenkins can be installed and used in Docker, FreeBSD, Gentoo, Mac OS X, OpenBSD, openSUSE, Red Hat/Fedora/CentOS, Ubuntu/ Debian and Windows.
The features of Jenkins are:
Support for SCM tools such as Git, Subversion, Star Team, CVS, AccuRev, etc.
Extensible architecture using plugins: The plugins available are for Android development, iOS development, .NET development, Ruby development, library plugins, source code management, build tools, build triggers, build notifiers, build reports, UI plugins, authentication and user management, etc.
It has the ‘Pipelines as a Code’ feature, which uses a domain-specific language (DSL) to create a pipeline to manage the application’s lifecycle.
The master agent architecture supports distributed builds. To install Jenkins, the minimum hardware requirements are 256MB of RAM and 1GB of drive space. The recommended hardware configuration for a small team is 1GB+ of RAM and 50 GB+ of drive space. You need to have Java 8 - Java Runtime Environment (JRE) or a Java Development Kit (JDK).
The easiest way to run Jenkins is to download and run its latest stable WAR file version. Download the jenkins.war file, go to that directory and execute the following command: java -jar jenkins.war.
Next, go to http://<localhost|IP address>:8080 and wait until the ‘Unlock Jenkins’ page appears. Follow the wizard instructions and install the plugins after providing proxy details (if you are configuring Jenkins behind a proxy).
To install plugins, go to Jenkins Dashboard > Manage Jenkins > Manage Plugins. Verify the updates as well as the available and the installed tabs. For the HTTP proxy configuration, go to the Advanced tab.
To manually upload plugins, go to Jenkins Dashboard > Manage Jenkins > Manage Plugins > Advanced > Upload Plugin.
To configure security, go to Jenkins Dashboard > Manage Jenkins > Configure Global Security. You can configure authentication using Active Directory, Jenkins’ own user database, and LDAP. You can also configure authorisation using Matrix-based security or the projectbased Matrix authorisation strategy.
To configure environment variables (such as ANDROID_ HOME), tool locations, SonarQube servers, Jenkins location, Quality Gates - Sonarqube, e-mail notification, and so on, go to Jenkins Dashboard > Manage Jenkins > Configure System.
To configure Git, JDK, Gradle, and so on, go to
Jenkins Dashboard > Manage Jenkins > Global Tool Configuration.
Creating a pipeline for Android applications
We have the following prerequisites:
Sample the Android application on GitHub, GitLab, SVN or file systems.
Download the Gradle installation package or configure it to install automatically from Jenkins Dashboard. Download the Android SDK.
Install plugins in Jenkins such as the Gradle plugin, the Android Lint plugin, the Build Pipeline plugin, etc.
Now, let’s look at how to create a pipeline using the Build Pipeline plugin so we can achieve the following tasks: Perform code analysis for Android application code using Android Lint.
Create an APK file.
Figure 1: Global tool configuration Figure 2: Gradle installation
Figure 3: ANDROID_HOME environment variable Figure 4: Source code management Figure 5: Lint configuration
Create a pipeline so that the first code analysis is performed and on its successful implementation, execute another build job to create an APK file.
Now, let’s perform each step in sequence.
Configuring Git, Java, and Gradle: To execute the build pipeline, it is necessary to take code from a shared repository. As shown below, Git is configured to go further. The same configuration is applied to all version control that is to be set up. The path in Jenkins is Home > Global tool configuration > Version control / Git.
Figure 6: Publish Android Lint results
In an Android project, the main part is Gradle, which is used to build our source code and download all the necessary dependencies required for the project. In the name field, users can enter Gradle with their version for better readability. The next field is Gradle Home, which is the same as the environment variable in our system. Copy your path to Gradle and paste it here. There is one more option, ‘Install automatically’, which installs Gradle’s latest version if the user does not have it.
Configuring the ANDROID_HOME environment variable: The next step is to configure the SDK for the Android project that contains all the platform tools and other tools also.
Here, the user has to follow a path to the SDK file, which is present in the system.
The path in Jenkins is Home> Configuration >SDK. Creating a Freestyle project to perform Lint analysis for the Android application: The basic setup is ready; so let’s start our project. The first step is to enter a proper name (AndroidApp-CA) to your project. Then select ‘Freestyle project’ under Category, and click on OK. Your project file structure is ready to use.
The user can customise all the configuration steps to show a neat and clean function. As shown in Figure 4, in a general configuration, the ‘Discard old build’ option discards all your old builds and keeps the number of the build at whatever the user wants. The path in Jenkins is Home> #your_project# > General Setting.
In the last step, we configure Git as version control to pull the latest code for the Build Pipeline. Select the Git option and provide the repository’s URL and its credentials. Users can also mention from which branch they want to take the code, and as shown in Figure 5, the ‘Master’ branch is applied to it. Then click the Apply and Save button to save all your configuration steps.
The next step is to add Gradle to the build, as well as add Lint to do static code analysis. Lint is a tool that performs code analysis for Android applications, just as Sonarqube does in Java applications. To add the Lint task to the configuration, the user has to write Lint options in the
build.gradle file in the Android project.
The Android Lint plugin offers a feature to examine the XML output produced by the Android Lint tool and provides the results on the build page for analysis. It does not run Lint, but Lint results in XML format must be generated and available in the workspace.
Creating a Freestyle project to build the APK file for the Android application: After completing the analysis of the code, the next step is to build the Android project and create an APK file to execute further.
Creating a Freestyle project with the name AndroidApp-APK: In the build actions, select Invoke Gradle script.
Archive the build artefacts such as JAR, WAR, APK or IPA files so that they can be downloaded later. Click on Save.
After executing all the jobs, the pipeline can be pictorially represented by using the Build Pipeline plugin. After installing that plugin, users have to give the start, middle and end points to show the build jobs in that sequence. They can configure upstream and downstream jobs to build the pipeline.
To show all the build jobs, click on the ‘+’ sign on the right hand side top of the screen. Select build pipeline view on the screen that comes up after clicking on this sign. Configuring a build pipeline view can be decided on by the user, as per requirements. Select AndroidApp-CA as the initial job.
There are multiple options like the Trigger Option, Display Option, Pipeline Flow, etc.
As configured earlier, the pipeline starts by clicking on the Run button and is refreshed periodically. Upstream and downstream, the job execution will take place as per the configuration.
After completing all the processes, you can see the visualisation shown in Figure 11. Green colour indicates the successful execution of a pipeline whereas red indicates an unsuccessful build.
Figure 7: Gradle build
Figure 9: Downstream job
Figure 8: Archive Artifact
Figure 11: Successful execution of the Build Pipeline
Figure 10: Build Pipeline flow