Jak GitLab przy użyciu fastlane buduje, podpisuje i publikuje aplikacje dla iOS w App Store.
Ostatnio mieliśmy z GitLab i Tutaj zobaczymy, jak zbudować i uruchomić aplikację iOS oraz opublikować ją w TestFlight. Zobaczcie, jakie to świetne, pobieram wersję roboczą aplikacji na tym samym iPadzie Pro, na którym ją stworzyłem.
Tutaj weźmiemy z którą nagrywałem wideo.
Kilka słów o konfiguracji Apple Store.
Potrzebujemy aplikacji w App Store, certyfikatów dystrybucji oraz profilu inicjalizacji, aby wszystko połączyć.
Najtrudniejsze jest skonfigurowanie uprawnień do podpisywania w App Store. Mam nadzieję, że sobie z tym poradzicie. Jeśli jesteście nowi, wskażę właściwy kierunek, ale nie będziemy tutaj omawiać szczegółów zarządzania certyfikatami Apple, które zresztą ciągle się zmieniają. Ten post pomoże Wam zacząć.
Moje aplikacje
Potrzebujesz aplikacji w App Store Connect, aby mieć ID do konfiguracji .xcodebuild.Profil i ID aplikacji łączą budowy kodu, ceny i dostępność, a także konfigurację TestFlight do dystrybucji testowych aplikacji wśród użytkowników. Nie rób testów publicznych, zamiast tego wystarczy prywatne, jeśli masz małą grupę, prostą konfigurację i nie potrzebujesz dodatkowych uprawnień od Apple.
Profil inicjalizacji
Poza konfiguracją aplikacji potrzebujesz kluczy dystrybucji i dewelopera iOS, stworzonych w sekcji Certyfikaty, Identyfikatory i Profile w konsoli Apple Developer. Wszystkie te certyfikaty można połączyć w profilu inicjalizacji.
Użytkownicy, którzy będą przechodzić autoryzację, muszą mieć możliwość tworzenia certyfikatów, w przeciwnym razie na etapach natkniesz się na błąd.
Inne opcje
Poza tą prostą metodą są też inne sposoby na skonfigurowanie certyfikatów i profili. Jeśli pracujesz w inny sposób, może być konieczne dostosowanie się. Najważniejsze — potrzebujesz konfiguracji, .xcodebuild.która wskaże odpowiednie pliki, a pęk kluczy musi być dostępny na komputerze kompilacji dla użytkownika, pod którego nazwiskiem działa runner. Do cyfrowego podpisywania używamy fastlane, a jeśli pojawią się problemy lub chcesz dowiedzieć się więcej, zapoznaj się z ich szczegółami. .
W tym przykładzie używam podejścia , ale w rzeczywistej aplikacji, prawdopodobnie lepiej sprawdzi się .
Przygotowanie GitLab i fastlane
Przygotowanie CI Runner
Zbierając te wszystkie dane, przechodzimy do konfiguracji GitLab runnera na urządzeniu MacOS. Niestety, tworzenie aplikacji iOS jest możliwe tylko w MacOS. Ale wszystko może się zmienić, a jeśli czekasz na postępy w tej dziedzinie, — obserwuj projekty, takie jak i , oraz nasze wewnętrzne zadanie .
Konfiguracja runnera jest bardzo prosta. Śledź aktualne .
Uwaga. Runner musi używać programu wykonywalnego shell. Jest to konieczne do budowy iOS w macOS, aby działać bezpośrednio jako użytkownik, a nie przez kontenery. Jeśli używasz shell, budowanie i testowanie odbywają się w imieniu użytkownika runnera, bezpośrednio na hoście budowy. Nie jest to tak bezpieczne, jak kontenery, więc lepiej przeglądnij , aby niczego nie przeoczyć.
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 startZestawienie kluczy Apple musi być skonfigurowane na tym hoście z dostępem do kluczy, które są potrzebne Xcode do budowy. Najprostszym sposobem na przetestowanie tego jest zalogowanie się jako użytkownik, który uruchomi budowę, i spróbować wykonać budowę ręcznie. Jeśli system poprosi o dostęp do zestawu kluczy, wybierz „Zawsze pozwalaj”, aby CI działał. Może warto się zalogować i obserwować pierwsze parę pipeline'ów, — upewnić się, że już nie proszą o zestaw kluczy. Problem w tym, że Apple nie ułatwia nam pracy w trybie automatycznym, ale gdy to skonfigurujesz, wszystko będzie w porządku.
fastlane init
Aby używać fastlane w projekcie, uruchom fastlane init. Po prostu śledź , szczególnie w sekcji dotyczącej , ponieważ potrzebujemy szybkiego i przewidywalnego uruchamiania przez automatyczny pipeline CI.
W katalogu projektu uruchom te polecenia:
xcode-select --install
sudo gem install fastlane -NV
# Alternatywnie korzystając z Homebrew
# brew cask install fastlane
fastlane initfastlane poprosi o podstawową konfigurację, a następnie utworzy w projekcie folder fastlane z trzema plikami:
1. fastlane/Appfile
Tutaj nie ma nic skomplikowanego. Po prostu sprawdź, czy Apple ID i ID aplikacji są poprawnie podane.
app_identifier("com.vontrance.flappybird") # Identyfikator pakietu Twojej aplikacji
apple_id("your-email@your-domain.com") # Twój adres e-mail Apple2. fastlane/Fastfile
Fastfile określa kroki kompilacji. Używamy wielu wbudowanych możliwości fastlane, więc wszystko jest tutaj jasne. Tworzymy jedną linię, która zdobywa certyfikaty, wykonuje kompilację i przesyła ją do TestFlight. Możesz podzielić ten proces na różne zadania, jeśli zajdzie taka potrzeba. Wszystkie te operacje (get_certificates, get_provisioning_profile, gym i upload_to_testflight) już są zawarte w fastlane.
Działania get_certificates i get_provisioning_profile są związane z podejściem do podpisywania . Jeśli używasz lub czegoś innego, dostosuj zmiany.
default_platform(:ios)
platform :ios do
desc "Zbuduj aplikację"
lane :flappybuild do
get_certificates
get_provisioning_profile
gym
upload_to_testflight
end
end3. fastlane/Gymfile
To jest opcjonalny plik, ale stworzyłem go ręcznie, aby zmienić domyślny katalog wyjściowy i umieścić wyjście w bieżącym folderze. To upraszcza CI. Jeśli chcesz, przeczytaj o gym i jego parametrach w .
https://docs.fastlane.tools/actions/gym/Nasza .gitlab-ci.yml
Więc mamy runnera CI dla projektu i jesteśmy gotowi przetestować pipeline. Zobaczmy, co mamy w .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.ipaWszystko w porządku! , używamy strategii clone z programem wykonawczym shell, abyśmy mieli czystą przestrzeń roboczą dla każdej kompilacji, i po prostu wywołujemy flappybuild fastlane, jak widać powyżej. W rezultacie otrzymujemy kompilację, podpis i wdrożenie ostatniej kompilacji do TestFlight.
Dodatkowo otrzymujemy artefakt i zapisujemy go razem z kompilacją. Zauważ, że format .ipa — to podpisany plik wykonywalny ARM, który nie działa w symulatorze. Jeśli chcesz dane wyjściowe dla symulatora, po prostu dodaj cel kompilacji, który to produkuje, a następnie uwzględnij go w ścieżce do artefaktu.
Inne zmienne środowiskowe
Tutaj jest kilka zmiennych środowiskowych, na których wszystko działa.
FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD i FASTLANE_SESSION
Do uwierzytelnienia w App Store i przesyłania do TestFlight potrzebna jest autoryzacja dla fastlane. W tym celu stwórz hasło dla aplikacji, które będzie używane w CI. Szczegóły .
Jeśli masz uwierzytelnianie dwuskładnikowe, utwórz zmienną FASTLANE_SESSION (instrukcje są tam same).
FASTLANE_USER i FASTLANE_PASSWORD
Aby wywoływał profil inicjalizacji i certyfikaty na żądanie, musisz ustawić zmienne FASTLANE_USER i FASTLANE_PASSWORD. Szczegóły . To nie jest konieczne, jeśli używasz innej metody podpisywania.
Na zakończenie
Zobacz, jak to wszystko działa .
Mam nadzieję, że to było pomocne i zainspirowałem Cię do pracy z kompilacjami iOS w projekcie GitLab. Oto jeszcze dla fastlane, na wszelki wypadek. Może zechcesz użyć CI_BUILD_ID (do inkrementacyjnych kompilacji), aby .
Jeszcze jedną świetną możliwością fastlane jest dla App Store, które bardzo łatwo skonfigurować.
Podziel się w komentarzach swoimi doświadczeniami i pomysłami na poprawę GitLab dla rozwoju aplikacji iOS.
Źródło: habr.com
