GitLab CI -Configure a Pipeline for iOS Project
In the previous article I explained, how to set up GitLab runner on your Mac. This time I will go further and configure a simple pipeline for an iOS project.
I will configure a pipeline, which will perform unit-tests for merge request and build the project on commit on the develop branch.
What you need to follow me:
- completed previous tutorial, i.e. configured gitlab runner on your Mac and an XCode Project
- your favourite fastlane script with couple of sample lanes, like “unit_test” and “build”
Learn the Language
There are some basic concepts, we need to know to understand all the CI-talking. And to use some buzzwords 🤓
The first one we learned last time: runner. It is software, running on our Mac, performing the work we define, and sending result back to GitLab.
Pipeline is the top-level component of continuous integration. You can find them in the side-menu in your Gitlab project under CI/CD -> Pipelines.
Pipeline consist of stages (one or more).
Stages in turn contain jobs, which define what should be done. Stage is something like coordinator, which tells, when which job is performed.
These components help us to structure the pipeline, break it up in smaller logical steps. It makes the yaml file easy to read, provides us with the visualisation in the GitLab UI and, probably the most important, supports us by troubleshooting. If we keep the jobs small we already have the first idea, what might have gone wrong, when looking at the image above.
For our rather simple use case we will use a basic pipeline. In that case jobs in the same stage run concurrently, and the stages sequentially (you can read more here).
Now let’s move to practice
Fastfile
If you are an iOS Developer, you are likely to use fastlane to run builds and tests. Just pick your favourite setup. I take a simple one with just three lanes: run tests, bump version and build project.
Configure Pipeline
The next step is to configure .gitlab-ci.yml file. The whole script you can find below. No we just take a look at it in details, step-by-step.
before_script: actions, which are performed before every jobs. Normally it is necessary setup.
unit_test: it is our custom job, which is performed on stage “test”. I defined, that the job should run only for merge requests. After the job is done, junit report should be uploaded to gitlab. Then we will be able to see the result in our merge request, as shown on the screenshot below
bump_version: This job increments the build number of the project and pushes it. I defined, that it should run for the stage bump_version, only for develop branch.
build_project: This job for the stage build is supposed to build the binary. After that, the binary is uploaded to the GitLab as artifact, I had just defined the path to it.
❗️It is important to know the order, in which the things happen. As already mentioned above, the jobs, which belong to the same stage are peformed concurrently. And the stages in the order, they are defined in the .gitlab-ci.yml file. Let have a look at our example. If develop branch is build, test-stage is skipped, because there no jobs of this stage, which should run for develop. At first the bump_version job runs, and after that build_project.
Conclusion
I personally find GitLabCI a good tool. You get it for free, if you are using Gitlab, it is good integrated and good documented. So you can just dive in and learn more.
