Jak GitLab z Fastlane zbiera, podpisuje i publikuje aplikacje iOS w App Store.
Niedawno mieliśmy z GitLabem i . Tutaj zobaczymy, jak zbudować i uruchomić aplikację na iOS i opublikować ją w TestFlight. Sprawdź jakie to fajne , przyjmuję montaż i otrzymuję aktualizację do wersji testowej aplikacji na tym samym iPadzie Pro, na którym ją opracowałem.
Tutaj zajmiemy , z którym nagrałem wideo.
Kilka słów o konfiguracji Apple Store
Aby połączyć wszystko w jedną całość, będziemy potrzebować aplikacji App Store, certyfikatów dystrybucyjnych i profilu udostępniania.
Najtrudniejszą rzeczą jest tutaj ustawienie praw do podpisywania w App Store. Mam nadzieję, że przekonasz się o tym sam. Jeśli jesteś nowy, wskażę Ci właściwy kierunek, ale nie będziemy tutaj rozmawiać o zawiłościach zarządzania certyfikatami Apple, a one ciągle się zmieniają. Ten post pomoże Ci zacząć.
Moje aplikacje
Potrzebujesz aplikacji w App Store Connect, aby mieć identyfikator do konfiguracji .xcodebuild. Profil i identyfikator aplikacji łączą kompilację kodu, cenę i dostępność oraz konfigurację TestFlight w celu dystrybucji aplikacji testowych wśród użytkowników. Nie wykonuj testów publicznych. Testy prywatne wystarczą, jeśli masz małą grupę, masz łatwą konfigurację i nie potrzebujesz dodatkowych uprawnień od Apple.
Profil inicjalizacji
Oprócz konfiguracji aplikacji potrzebne są klucze dystrybucyjne i programistyczne systemu iOS utworzone w sekcji Certyfikaty, identyfikatory i profile w konsoli programisty Apple. Wszystkie te certyfikaty można połączyć w profil udostępniania.
Użytkownicy, którzy zostaną uwierzytelnieni, muszą mieć możliwość tworzenia certyfikatów, w przeciwnym razie wykonaj poniższe kroki zobaczysz błąd.
inne opcje
Oprócz tej prostej metody istnieją inne sposoby konfigurowania certyfikatów i profili. Jeśli więc pracujesz inaczej, być może będziesz musiał się dostosować. Najważniejsze jest to, że potrzebujesz konfiguracji .xcodebuild, który wskaże niezbędne pliki, a pęk kluczy musi być dostępny na komputerze kompilacji dla użytkownika, pod którego nazwą biegacz biegnie. Do podpisu cyfrowego używamy Fastlane, a jeśli pojawią się problemy lub chcesz dowiedzieć się więcej, sprawdź ich szczegóły .
W tym przykładzie używam podejścia , ale do prawdziwego użytku prawdopodobnie lepiej się nadaje .
Przygotowanie GitLaba i fastlane
Przygotowanie CI Runnera
Po zebraniu tych wszystkich danych przystępujemy do konfiguracji runera GitLab na urządzeniu z systemem MacOS. Niestety aplikacje na iOS można tworzyć tylko na MacOS. Ale wszystko może się zmienić, a jeśli spodziewasz się postępu w tej dziedzinie, miej oko na projekty takie jak и i nasze wewnętrzne zadanie .
Konfiguracja biegacza jest bardzo prosta. Podążaj za prądem .
Notatka. Biegacz musi używać programu wykonywalnego shell. Jest to wymagane, aby system iOS na macOS działał bezpośrednio jako użytkownik, a nie za pośrednictwem kontenerów. Jeśli używasz shell, budowanie i testowanie są wykonywane jako użytkownik uruchamiający, bezpośrednio na hoście kompilacji. Nie jest tak bezpieczny jak kontenery, więc lepiej przeglądaj więc nic Ci nie umknie.
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 startNa tym hoście należy skonfigurować pęk kluczy Apple z dostępem do kluczy, które Xcode musi zbudować. Najłatwiejszym sposobem przetestowania tego jest zalogowanie się jako użytkownik, który uruchomi kompilację, i próba zbudowania jej ręcznie. Jeśli system poprosi o dostęp do pęku kluczy, wybierz opcję Zawsze zezwalaj na działanie CI. Może warto wejść i obejrzeć kilka pierwszych potoków, aby upewnić się, że nie proszą już o breloczek do kluczy. Kłopot w tym, że Apple nie ułatwia nam korzystania z trybu Auto, ale gdy już go uruchomimy, wszystko będzie dobrze.
inicjalizacja fastlane
Aby użyć Fastlane w projekcie, uruchom fastlane init. Po prostu podążaj zwłaszcza w części o , ponieważ potrzebujemy szybkiego i przewidywalnego uruchomienia za pośrednictwem zautomatyzowanego rurociągu CI.
W katalogu projektu uruchom następujące polecenia:
xcode-select --install
sudo gem install fastlane -NV
# Alternatively using 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
Nie ma tu nic skomplikowanego. Upewnij się tylko, że identyfikator Apple ID i identyfikator aplikacji są prawidłowe.
app_identifier("com.vontrance.flappybird") # The bundle identifier of your app
apple_id("[email protected]") # Your Apple email address2. fastlane/Fastfile
Fastfile definiuje kroki kompilacji. Korzystamy z wielu wbudowanych funkcji Fastlane, więc i tutaj wszystko jest jasne. Tworzymy jedną linię, która odbiera certyfikaty, wykonuje montaż i przesyła go do TestFlight. W razie potrzeby możesz podzielić ten proces na różne zadania. Wszystkie te operacje (get_certificates, get_provisioning_profile, gym и upload_to_testflight) są już uwzględnione w Fastlane.
Działalność get_certificates и get_provisioning_profile związane ze sposobem podpisywania . Jeśli używasz czy cokolwiek, wprowadź zmiany.
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
Jest to plik opcjonalny, ale utworzyłem go ręcznie, aby zmienić domyślny katalog wyjściowy i umieścić dane wyjściowe w bieżącym folderze. Upraszcza to CI. Jeśli jesteś zainteresowany, przeczytaj o gym i jego parametry w .
https://docs.fastlane.tools/actions/gym/Nasz .gitlab-ci.yml
Mamy więc moduł CI dla projektu i jesteśmy gotowi przetestować potok. Zobaczmy, co mamy w sobie .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 jest w porządku! , użyj strategii clone z wykonywanym programem shell, dzięki czemu mamy czystą przestrzeń roboczą dla każdego montażu i po prostu wywołujemy flappybuild Fastlane, jak widać powyżej. W rezultacie otrzymujemy montaż, sygnaturę i wdrożenie najnowszego zestawu w TestFlight.
Otrzymujemy również artefakt i zapisujemy go wraz z montażem. Należy pamiętać, że format .ipa to podpisany plik wykonywalny ARM, który nie działa w symulatorze. Jeśli chcesz uzyskać dane wyjściowe dla symulatora, po prostu dodaj element docelowy kompilacji, który je generuje, a następnie dołącz go do ścieżki artefaktu.
Inne zmienne środowiskowe
Jest tu kilka zmiennych środowiskowych, dzięki którym wszystko działa.
FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD и FASTLANE_SESSION
Uwierzytelnienie dla Fastlane jest wymagane do uwierzytelnienia w App Store i przesłania do TestFlight. W tym celu utwórz hasło do aplikacji, która będzie używana w CI. Detale .
Jeśli masz uwierzytelnianie dwuskładnikowe, utwórz zmienną FASTLANE_SESSION (tam instrukcja).
FASTLANE_USER и FASTLANE_PASSWORD
Że nazywany profilem inicjalizacyjnym i certyfikatami na żądanie, należy ustawić zmienne FASTLANE_USER и FASTLANE_PASSWORD. Detale . Nie jest to konieczne, jeśli używasz innej metody podpisywania.
Na zakończenie
Możesz zobaczyć jak to wszystko działa .
Mam nadzieję, że było to pomocne i zainspirowało Cię do pracy z kompilacjami iOS w projekcie GitLab. Oto kolejny dla Fastlane, na wszelki wypadek. Może zechcesz skorzystać CI_BUILD_ID (w przypadku kompilacji przyrostowych) do .
Kolejną fajną funkcją Fastlane jest dla App Store, które są bardzo łatwe w konfiguracji.
Opowiedz nam w komentarzach o swoich doświadczeniach i podziel się pomysłami na ulepszenie tworzenia aplikacji GitLab dla iOS.
Źródło: www.habr.com