In order to build and upload your iOS apps with GitLab CI, you need to set up Fastlane first. Once you are able to build and upload your app locally using Fastlane, setting up GitLab CI is just a matter of running Fastlane from your
Below you can see an example
.gitlab-ci.yml File. If you just want to get your build up and running, follow these steps:
.gitlab-ci.yml File to your project root
Gemfile example from below to your project root
Make sure you have set up Fastlane with a lane called
Ensure that for Fastlane you use an environment file called
Set up a GitLab CI build agent that can handle iOS builds (more on this below)
Once you fulfill these requirements, pushing to the
develop branch should automatically trigger a build and upload the finished app to Updraft.
If you want to take a deep dive and customize your build, here's an overview over the different components of the
stages:- build_updraftvariables:LC_ALL: "en_US.UTF-8"LANG: "en_US.UTF-8"before_script:- gem install bundler- bundle installbuild_updraft:dependencies: stage: updraft_stagingscript:- fastlane deploy_updraft --env updrafttags:- ios-devonly:- develop
First you declare your build stages (just
build_updraft in this case). Think of these like different Lanes in Fastlane. You could set up different build stages for different branches, or run multiple build stages in succession. We recommend starting with just one stage, you can always set up more builds later, for example if you want to build your app for both a staging and production CMS at the same time.
The next interesting part is
before_script. Here you can set some shell commands to be run before any of the build stages. In this case, we want to make sure that the build runner ("agent") where the actual build will happen has the necessary dependencies, most likely Fastlane and Cocoapods. These commands simply tell the machine to install any Gems specified in the
Gemfile. You can just place the
Gemfile from the example below in your project directory.
source "https://rubygems.org"gem "fastlane"gem "cocoapods"
build_updraft is where the rest of the magic happens. The important part is the
script tag where all we do is call Fastlane, which will handle the rest of the build and upload process. Notice we have a lane in our Fastfile called
deploy_updraft and we are using a file named
.env.updraft where we set all the variables that Fastlane needs.
Again, if you are unsure on how to do this, check out the Fastlane setup guide. The
tags section is used to select the correct build agent. Since you only want build runners that can handle iOS (i.e. macOS machines with Xcode installed) to run your build, you need to set this tag on both your build stage and during the setup of your build runner. The last section,
only, makes sure that the branch is run only when pushing to the
develop branch. You can adapt this to your branching setup or remove it entirely if you want to build from all branches. You can even use a Regex Syntax, for example
/^release\/.*$/ to build from any release branch.
A build runner is a physical or virtual machine that has the necessary tools to run your builds. As an iOS Dev, you probably know you need a macOS Machine with Xcode Tools to build your iOS apps. In our Office, we use Mac Minis for this.
Once you have a machine that can handle iOS Builds, you can follow the steps in the GitLab Documentation to set up your own runner. Make sure to specify the same
tag as you used in your
.gitlab-ci.yml file to restrict the runner to accept only iOS Builds.
If you've read until here, you have earned our respect! We hope our guide has been helpful to you. If you have any questions, feel free to contact our support.