Building Android with BitBucket Pipelines
We all have our preferences when it comes to development and the repository is no exception: if you happen to use Atlassian’s solution and you want to build your Android project automatically, Pipelines are the tool you’re looking for: this new feature, completely free at the time of writing, is a Docker-based solution for continuous integration hosted onto Atlassian’s cloud, definitely helpful, not necessarily easy to grasp.
Creating the script
Usually, this is the last step of the chain but, since as soon as we enable the pipelines, the remote build will start to fail if the script isn’t in the repo, we’d better create it right away and forget about it.
The primary duty of this script is accepting the Android SDK license and start the build of our project: in the example, we invoke the
assembleDebug task, but you can use whatever you need.
In the root folder of our project, we need to create a file named
build.sh in which we put the following content:
The first thing this script does (line 3) is creating a
licenses folder in the Android SDK path and then putting a value in the
android-sdk-license file: this value is not random nor personal, but is the hash that confirms that we agreed on the Terms and Conditions of the SDK itself (if we didn’t the build would fail, asking us to agree on those terms).
At this point, we invoke our build by using the
gradlew executable, as we would in Android Studio.
If you were to use the preview version of the Android SDK, you would have had to put the value
84831b9409646a918e30573bab4c9c91346d8abdin a file named
android-sdk-preview-licensein the same
licensefolder. In case you lost these hashes, you can always read them in your local installation of the Android SDK (or its preview version) in the aforementioned
Pushing the script to the repo
git is something we are usually used to, and sending a file to our repo is really simple but this time there’s a catch: we need this script to be executed, in order to have our build triggered. But it has not the execution permission. We can fix that by invoking this
git update-index --chmod=+x build.sh
If we try and run a
git status now, we could see something strange: a tracked version of the
build.sh file and an untracked one. If this is your case, you can ignore (for the moment) the untracked version of the file and just commit the tracked version to the repo.
Now, we still have to deal with the untracked version of the script: if we commit it, we would lose the execution permissions on the script in the repo and we could not run the build. This happens because
git is uncertain on how to deal with permission changes, but we can instruct it to ignore the mode changing bit for the repo by invoking this command:
git config core.fileMode false
Enabling the service
In order to use this feature, we just need to click on the
Pipelines entry on the left menu and then do the same thing on the blue button in the central part of the window, the one labeled
Enable Pipelines. At this point, we are asked to select a template, but there isn’t one for building Android yet, so we select the
Other entry and go on.
Now, we have to create our build script but, thanks to the Uber team and this StackOverflow answer, we are pretty safe on that part and we can just past this code in the Pipeline script editor:
What this script does is essentially selecting a pre-made (by the aforementioned Uber team) Docker image ready to compile Android projects, using it to invoke the
build.sh script we already created in our project.
By now, your pipeline should have started, the Docker image should have been loaded and (hopefully) the script executed. You can sit and relax, the whole process could take a while (and it will start at every commit you push), but at least it won’t be running on your machine.