GitLab iOS with Fastlane
Gitlab CI/CD can be used to deploy iOS apps with Fastlane to Updraft.
Uploading a build to Updraft with Gitlab
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 .gitlab-ci.yml
script.
Quick Start
Below you can see an example .gitlab-ci.yml
File. If you just want to get your build up and running, follow these steps:
Copy the
.gitlab-ci.yml
File to your project rootCopy the
Gemfile
example from below to your project rootMake sure you have set up Fastlane with a lane called
build_updraft
Ensure that for Fastlane you use an environment file called
.env.updraft
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 .gitlab-ci.yml
setup.
EXAMPLE .GITLAB-CI.YML
.GITLAB-CI.YML
Detailed Discussion
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.
EXAMPLE GEMFILE
GEMFILE
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.
Setting up a Build Runner
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.
Last updated