Using Bitrise as a CI Server

Introduction

Previously, we created a simple CI using Fastlane. However there was a small thing we missed. This way, we had to launch our fastlane CI lane every time we wanted it to perform the tests, linters, etc … What if I told you we can automate it, and that doesn’t involve your computer! Let me introduce you Bitrise 🎉.

Bitrise is a simple CI/CD server that will host our fastlane lane and will launch it at every pull requests.

The magical thing about Bitrise, is that we won’t need Sys-admin nor Devops talents! Everything is wrapped so we just have to give our fastlane and project and everything works.

Let’s start our journey by signing-in using this link

To check out the previous tutorial about fastlane, click here. You can continue this tutorial without the previous one, but we’ll need a project with fastlane set up.

Bitrise

Setup

After we’ve signed in, it’s time to add our project on Bitrise.

We click on Add new App and select Add new App on web UI.

Choose if we want our project to be public or private. If public, everyone can access it, whereas private, only us or the organization can see it.

The next step is to set up the repository. As we can see, Github, Gitlab and Bitbucket are well integrated, if we are connected with one of these we see all our repositories. If we want to add it manually, we can still add the url of the repository.

Now Bitrise asks us if we want to auto-add SSH key or not. The latter, allows us to generate one, that will be used to fetch other repositories like for fastlane match (to fetch certificates) or private cocoapods frameworks. For our tutorial we can auto-add one.

At this stage, Bitrise will analyze our repository to find what project is there. Is it an Android project? Is it an iOS project? It can also know if it uses fastlane. The purpose of this step is to pre-create a small CI script for Bitrise and select the right environment to launch. For iOS it has to be macOS. In our project, we choose Fastlane.

The last two steps are, add a logo for the project and add webhooks. For now, we can skip those two. At the end, Bitrise launches the first test build for us.

As we can see Bitrise will set up many things for us. It’s one of the strength of this tool. If we don’t want to do many things or just want to spend time coding and scripting. We also don’t care about the server that is launching our CI, we just know it can launch our fastlane lane. Which is enough for us.

Script

Now let’s check the preset script that is used for this first build.

To see it, let’s click on the big green button, which says We’ve kicked off your first test build for you!, to be redirected to the first build. This view is the result of our build, where we can see logs and artifacts.

Now we can go to the workflow editor. There are many tabs

• workflows to create different scripts.
• Code Signing to add our profile and certificate.
• Secrets and Env Vars to add environments variables for the script.
• Triggers to add hooks.
• Stack shows the OS, xcode version and all the environments where we run in.
• Bitrise.yml that is a file that gives all the information (workflows, triggers, stack) as a yml file.

In this tutorial, we will only use the workflows tab.

As we can see, there are a lot of things that we don’t need. First, let’s see step-by-step what we have.

1. activate the ssh-key. We need it to clone the repository.

2. clone the repository. Same here, we need it.

3. a simple script that print “Hello World”. We can delete it.

4. install certificates and profiles. We won’t need it in our CI. So let’s delete this too.

5. install bundler, we can delete this too.

6. our fastlane. Let’s run our ci lane. To do so, update the fastlane lane input variable to ci.

7. deploy artifacts, logs and apps to Bitrise. We can keep it and update the Deploy directory or file path to Build.

Our script should look like this

As we can see, the script is quite simple. It will activate the correct ssh key, clone, run fastlane, and upload our artifacts to Bitrise.

We finished the hard part of Bitrise. Quite easy, right?

Hooks

Now let’s talk about hooks. When do we want our script to run? It’s a tough question, and there is no universal answer. For me the least we can do is to run the CI for every pull/merge requests. Like that, every time we want to integrate our code, it is compiled, tested and linted.

Let’s go to the trigger tab! We can see that we can add triggers for push, pull request and tag. For our purpose we can delete the trigger already present and add a new one on pull request, we don’t have to change the source and the target branches and we set the primary workflow. As we can see, the branch names can be a regex, it’s quite useful when we want to run different scripts depending on if it’s a feature/* branch or a release/* one (if we follow gitflow).

In Bitrise we can add multiple workflows (e.g. one for the CI that runs for every branches and another for the CD - Continuous Delivery - that runs only on release/*).

Github

Now we have our simple CI hosted in Bitrise. We can see that it’s quite easy, but we don’t have any feedback in our pull requests.

Let’s add a check on it. If Bitrise has already run for any pull request, we can go to the settings of our repository. In branches, we can add Branch Protection Rule and set Require status checks to pass before merging. There is one that has something like ci/bitrise/***/pr for the pull request.

As we can see our pull request now looks like this.

Go further

We could add other checks to our pull request, like swiftlint or even code coverage to be higher than previously.

Here is a screenshot of what could be a pull request using those two.