GitLab iOS with Fastlane
Gitlab CI/CD can be used to deploy iOS apps with Fastlane to Updraft.
Last updated
Gitlab CI/CD can be used to deploy iOS apps with Fastlane to Updraft.
Last updated
In order to build and upload your iOS apps with GitLab CI, you need to set up 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.
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 root
Copy the Gemfile example from below to your project root
Make 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.
.GITLAB-CI.YML 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.
GEMFILEbuild_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.
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.
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.
Again, if you are unsure on how to do this, check out the 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.
Once you have a machine that can handle iOS Builds, you can follow the steps in the 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.