An iOS Developer’s reflection about Continuous Integration

As a young iOS developer I have been trying to find a solution to automate my Unit test, Gitlab was the best answer for me. Gitlab provides an integrated Continuous integration service that is enabled on all projects by default.

In order to activate CI on my project I had to perform two major steps:

1. Add .gitlab-ci.yml file to the root directory of my repository ;
2. Configure a Runner

The Gitlab Runner:

According to Gitlab, runners are defined “ an Isolated (virtual) machines that pick up jobs through the coordinator API of GitLab CI.” A runner can either be Shared or Specific.

In this article I’m going to show you how I installed then configured A Specific Runner on a Mac.

The easiest way to install a Gitlab runner is to go through the homebrew which is a free and open source package management software for MacOS. (https://brew.sh/index_fr )

• Use the command brew install gitlab-runner in Terminal
• go to your project in GitLab and select Settings > CI/CD, then choose Expand Runner
• Third, disable shared runners :

• Finally, go to Specific Runners and save your GitLab server url and token,

• Enter this command gitlab-runner register

1. when prompted, enter the url form above

2. next up, enter the registration token

3. name your runner

4. leave the tags blank

5. use the shell executor

If you find difficulties to follow the steps you can proceed as above.

You can follow this link to register the runner (https://docs.gitlab.com/runner/register/)

• Under your home directory, start your runner using these two commands

1. gitlab-runner install
2. gitlab-runner start

To make sure that everything is working okay for your runner, see:

Now let’s create a .gitlab-ci.yml to run the CI:

Here we have created a Job called Build; which cleans the project then builds it.

And now every Push or commit will trigger a Pipeline. If you wonder what’s a Pipeline,

Pipelines are the top-level component of continuous integration, delivery and deployment. It comprises :

1. Jobs that define what to run e.g. code compilation or test runs
2. Stages that define when and how to run e.g. that tests run only after code compilation.

After Pushing the code to Gitlab we triggered our pipeline, and there you can see the job starting

There you see our job succeed

Next article will be about Continuous deployment with Fastlane

To Be continued…