How GitLab with fastlane collects, signs and publishes iOS apps in the App Store.
We recently had with GitLab and . Here we will see how to build and run an iOS app and publish it to TestFlight. Check out how cool , I take the build and get an update to the test version of the application on the same iPad Pro where I developed it.
Here we take with which I recorded the video.
A few words about the configuration of the Apple Store
We'll need an app in the App Store, distribution certificates, and a provisioning profile to tie everything together.
The most difficult thing here is to set up signing permissions in the App Store. I hope you can figure this out for yourself. If you're new, I'll point you in the right direction, but we won't talk about the intricacies of managing Apple certificates here, and they're constantly changing. This post will help you get started.
My Apps
Need an app in App Store Connect so you have an ID to configure .xcodebuild. The app profile and ID combine code builds, pricing and availability, and the TestFlight configuration for distributing test apps to users. Do not do public testing, private testing is enough if you have a small group, simple setup and do not need additional permissions from Apple.
Provisioning Profile
In addition to the app setup, you need the iOS distribution and development keys created in the Certificates, Identifiers & Profiles section of the Apple Developer console. All of these certificates can be combined in a provisioning profile.
Users who will be authenticated need the ability to create certificates, otherwise the steps you will see an error.
Other options
Besides this simple method, there are other ways to set up certificates and profiles. So, if you work differently, you may have to readjust. Most importantly, you will need a configuration .xcodebuild, which will point to the necessary files, and the keychain must be available on the build computer for the user under whose name the runner is running. We use fastlane for digital signing, and if you have problems or want to know more, check out their detailed .
In this example I am using the approach , but for real use, probably better suited .
Preparing GitLab and fastlane
Preparing CI Runner
Having collected all this data, we move on to the configuration of the GitLab runner on a MacOS device. Unfortunately, making iOS apps is only possible on MacOS. But everything can change, and if you are waiting for progress in this area, follow projects like и , and our internal task .
Setting up the runner is very easy. Follow up-to-date .
Note. The runner must use an executing program shell. This is required to build iOS on macOS to work directly as a user and not through containers. If you are using shell, building and testing are done as the runner user, right on the build host. It's not as safe as containers, so you better flip so you don't miss anything.
sudo curl --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-darwin-amd64
sudo chmod +x /usr/local/bin/gitlab-runner
cd ~
gitlab-runner install
gitlab-runner startApple Keychain must be set up on this host with access to the keys that Xcode needs to build. The easiest way to test this is to log in as the user who will run the build and try to build manually. If the system asks for keychain access, select "Always allow" for CI to work. It might be worth going in and watching the first pair of pipelines to make sure they don't ask for a keychain anymore. The trouble is that Apple does not make it easy for us to work with automatic mode, but when you get it set up, everything will be fine.
fastlane init
To use fastlane in a project, run fastlane init. Just follow especially in the section on , because we need a fast and predictable launch through an automatic CI pipeline.
In the project directory, run these commands:
xcode-select --install
sudo gem install fastlane -NV
# Alternatively using Homebrew
# brew cask install fastlane
fastlane initfastlane will request a basic configuration and then create a fastlane folder in the project with three files:
1. fastlane/Appfile
There's nothing complicated here. Just make sure your Apple ID and App ID are correct.
app_identifier("com.vontrance.flappybird") # The bundle identifier of your app
apple_id("[email protected]") # Your Apple email address2. fastlane/Fastfile
Fastfile defines build steps. We use a lot of fastlane's built-in features, so everything is clear here too. We create one line that receives certificates, builds and uploads it to TestFlight. You can divide this process into different tasks if needed. All these operationsget_certificates, get_provisioning_profile, gym и upload_to_testflight) are already included in fastlane.
Actions get_certificates и get_provisioning_profile associated with the signing approach . If you are using or something else, make changes.
default_platform(:ios)
platform :ios do
desc "Build the application"
lane :flappybuild do
get_certificates
get_provisioning_profile
gym
upload_to_testflight
end
end3. fastlane/Gymfile
This is an optional file, but I created it manually to change the default output directory and put the output in the current folder. This simplifies CI. If interested, read about gym and its parameters in .
https://docs.fastlane.tools/actions/gym/Our .gitlab-ci.yml
So, we have a CI runner for the project and we are ready to test the pipeline. Let's see what we have .gitlab-ci.yml:
stages:
- build
variables:
LC_ALL: "en_US.UTF-8"
LANG: "en_US.UTF-8"
GIT_STRATEGY: clone
build:
stage: build
script:
- bundle install
- bundle exec fastlane flappybuild
artifacts:
paths:
- ./FlappyBird.ipaAll perfectly! , we use the strategy clone with executing program shellso that we have a clean workspace for each build, and just call flappybuild fastlane as seen above. As a result, we get the assembly, signature and deployment of the latest assembly in TestFlight.
We also get an artifact and save it with the assembly. Note that the format .ipa is a signed ARM executable that does not run in the simulator. If you want simulator output, just add the build target that produces it, and then include it in the artifact path.
Other environment variables
There are a couple of environment variables here that everything works on.
FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD и FASTLANE_SESSION
To authenticate to the App Store and upload to TestFlight, you need authentication for fastlane. To do this, create an application password that will be used in CI. Details .
If you have two-factor authentication, create a variable FASTLANE_SESSION (instructions there).
FASTLANE_USER и FASTLANE_PASSWORD
That called the initialization profile and certificates on request, you need to set variables FASTLANE_USER и FASTLANE_PASSWORD. View details . This is not needed if you are using a different signing method.
In conclusion
You can see how it all works .
I hope this was helpful and inspired you to work with iOS builds in the GitLab project. Here's another for fastlane, just in case. Maybe you want to use CI_BUILD_ID (for incremental builds) to .
Another cool feature of fastlane is for the App Store, which are very easy to set up.
Tell us about your experience in the comments and share ideas for improving GitLab for iOS app development.
Source: habr.com