Как GitLab с fastlane собирает, подписывает и публикует приложения для iOS в App Store.
Недавно у нас был с GitLab и . Здесь мы увидим, как собрать и запустить приложение iOS и опубликовать его в TestFlight. Зацените, как круто , беру сборку и получаю обновление тестовой версии приложения на том же iPad Pro, где я его разработал.
Здесь мы возьмем , с которым я записывал видео.
Пара слов о конфигурации Apple Store
Нам понадобится приложение в App Store, сертификаты распространения и профиль инициализации, чтобы связать все вместе.
Самое сложное тут — настроить права на подпись в App Store. Надеюсь, с этим вы разберетесь сами. Если вы новичок, я укажу нужное направление, но здесь мы не будем говорить о тонкостях управления сертификатами Apple, к тому же они постоянно меняются. Этот пост поможет приступить к делу.
Мои приложения
Нужно приложение в App Store Connect, чтобы у вас был ID для конфигурации .xcodebuild. Профиль и ID приложения объединяют сборки кода, цены и доступность, а еще конфигурацию TestFlight для распространения тестовых приложений среди пользователей. Не делайте общедоступное тестирование, хватит и приватного, если у вас маленькая группа, простая настройка и не нужны дополнительные разрешения от Apple.
Профиль инициализации
Кроме сетапа приложения вам нужны ключи распространения и разработки iOS, созданные в разделе Certificates, Identifiers & Profiles (Сертификаты, идентификаторы и профили) в консоли Apple Developer. Все эти сертификаты можно объединить в профиле инициализации.
Пользователям, которые будут проходить аутентификацию, нужна возможность создавать сертификаты, иначе на этапах вы увидите ошибку.
Другие варианты
Кроме этого простого метода, есть и другие способы настроить сертификаты и профили. Так что, если работаете иначе, возможно, придется перестраиваться. Самое главное — вам понадобится конфигурация .xcodebuild, которая будет указывать на нужные файлы, а связка ключей должна быть доступна на компьютере сборки для пользователя, под чьим именем работает раннер. Для цифровой подписи мы используем fastlane, и если есть проблемы или вы хотите узнать больше, изучите их подробную .
В этом примере я использую подход , но для реального применения, наверное, лучше подойдет .
Подготовка GitLab и fastlane
Подготовка CI Runner
Собрав все эти данные, переходим к конфигурации GitLab-раннера на устройстве MacOS. К несчастью, делать приложения iOS реально только в MacOS. Но все может измениться, и если ждете подвижек в этой области, — следите за проектами, вроде и , и нашей внутренней задачей .
Настроить раннер очень просто. Следуйте актуальным .
Примечание. Раннер должен использовать исполняющую программу shell. Это обязательно для сборки iOS в macOS, чтобы работать напрямую как пользователь, а не через контейнеры. Если вы используете shell, сборка и тестирование выполняются от имени пользователя раннера, прямо на хосте сборки. Это не так безопасно, как контейнеры, так что лучше пролистайте , чтобы ничего не упустить.
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 startСвязка ключей Apple должна быть настроена на этом хосте с доступом к ключам, которые нужны Xcode для сборки. Самый простой способ это протестировать — войти как пользователь, который запустит сборку, и попробовать выполнить сборку вручную. Если система запросит доступ к связке ключей, выберите «Всегда разрешать», чтобы CI работал. Возможно, стоит войти и понаблюдать за первой парой пайплайнов, — убедиться, что они больше не просят связки ключей. Беда в том, что Apple не упрощает нам работу с автоматическим режимом, но когда вы его наладите, все будет нормально.
fastlane init
Чтобы использовать fastlane в проекте, запустите fastlane init. Просто следуйте , особенно в разделе про , ведь нам нужен быстрый и предсказуемый запуск через автоматический конвейер CI.
В каталоге проекта запустите эти команды:
xcode-select --install
sudo gem install fastlane -NV
# Alternatively using Homebrew
# brew cask install fastlane
fastlane initfastlane запросит базовую конфигурацию, а потом создаст в проекте папку fastlane с тремя файлами:
1. fastlane/Appfile
Тут ничего сложного. Просто проверьте, что Apple ID и ID приложения указаны правильно.
app_identifier("com.vontrance.flappybird") # The bundle identifier of your app
apple_id("[email protected]") # Your Apple email address2. fastlane/Fastfile
Fastfile определяет шаги сборки. Мы используем много встроенных возможностей fastlane, так что здесь все тоже понятно. Создаем одну линию, которая получает сертификаты, выполняет сборку и загружает ее в TestFlight. Можете разделить этот процесс на разные задания, если нужно. Все эти операции (get_certificates, get_provisioning_profile, gym и upload_to_testflight) уже входят в fastlane.
Действия get_certificates и get_provisioning_profile связаны с подходом подписания . Если вы используете или что-то еще, внесите изменения.
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
Это необязательный файл, но я создал его вручную, чтобы изменить выходной каталог по умолчанию и поместить выходные данные в текущую папку. Это упрощает CI. Если интересно, читайте о gym и его параметрах в .
https://docs.fastlane.tools/actions/gym/Наш .gitlab-ci.yml
Итак, у нас есть CI-раннер для проекта, и мы готовы испытать пайплайн. Посмотрим, что у нас в .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.ipaВсе отлично! , используем стратегию clone с исполняющей программой shell, чтобы у нас было чистое рабочее пространство для каждой сборки, и просто вызываем flappybuild fastlane, как видно выше. В итоге мы получаем сборку, подпись и деплой последней сборки в TestFlight.
Еще получаем артефакт и сохраняем его со сборкой. Заметьте, что формат .ipa — это подписанный исполняемый файл ARM, который не запускается в симуляторе. Если хотите выходные данные для симулятора, просто добавьте таргет сборки, который его производит, а потом включите его в путь к артефакту.
Другие переменные среды
Здесь есть пара переменных среды, на которых все работает.
FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD и FASTLANE_SESSION
Для аутентификации в App Store и загрузки в TestFlight нужна аутентификация для fastlane. Для этого создайте пароль для приложения, который будет использоваться в CI. Подробности .
Если у вас двухфакторная аутентификация, создайте переменную FASTLANE_SESSION (инструкции там же).
FASTLANE_USER и FASTLANE_PASSWORD
Чтобы вызывали профиль иницализации и сертификаты по запросу, нужно задать переменные FASTLANE_USER и FASTLANE_PASSWORD. Подробности . Это не нужно, если вы используете другой метод подписания.
В заключение
Посмотреть, как все это работает, можно .
Надеюсь, это было полезно, и я вдохновил вас работать со сборками iOS в проекте GitLab. Вот еще для fastlane, на всякий случай. Может, захотите использовать CI_BUILD_ID (для инкрементных сборок), чтобы .
Еще одна крутая возможность fastlane — для App Store, которые очень просто настроить.
Расскажите в комментариях о своем опыте и поделитесь идеями по улучшению GitLab для разработки приложений iOS.
Источник: habr.com