Cum GitLab folosește fastlane pentru a compila, semna și publica aplicații iOS în App Store.
Recent am avut cu GitLab și . Aici vom vedea cum să compilăm și să lansăm o aplicație iOS și să o publicăm în TestFlight. Uită-te cât de grozav , iau construcția și primesc actualizarea versiunii beta a aplicației pe același iPad Pro unde am dezvoltat-o.
Aici vom lua , cu care am realizat un videoclip.
Câteva cuvinte despre configurația Apple Store
Vom avea nevoie de o aplicație în App Store, certificate de distribuție și un profil de inițializare pentru a lega totul împreună.
Cel mai complicat aici este să configurezi permisiunile de semnare în App Store. Sper că te vei descurca cu asta pe cont propriu. Dacă ești începător, îți voi indica direcția necesară, dar aici nu vom discuta despre subtilitățile gestionării certificatelor Apple, mai ales că acestea se schimbă constant. Această postare te va ajuta să începi.
Aplicațiile mele
Ai nevoie de o aplicație în App Store Connect pentru a avea un ID pentru configurație .xcodebuild. Profilul și ID-ul aplicației leagă construcțiile de cod, prețurile și disponibilitatea, precum și configurația TestFlight pentru distribuirea aplicațiilor beta utilizatorilor. Nu face teste publice, este suficient un test privat dacă ai un grup mic, o configurație simplă și nu ai nevoie de permisiuni suplimentare de la Apple.
Profilul de inițializare
În afară de setarea aplicației, ai nevoie de chei de distribuție și dezvoltare iOS, create în secțiunea Certificates, Identifiers & Profiles (Certificat, Identificatori și Profiluri) din consola Apple Developer. Toate aceste certificate pot fi combinate într-un profil de inițializare.
Utilizatorii care vor trece prin autentificare trebuie să aibă capacitatea de a crea certificate, altfel în etapele veți vedea o eroare.
Alte opțiuni
Pe lângă această metodă simplă, există și alte modalități de a configura certificatele și profilurile. Așadar, dacă lucrezi diferit, s-ar putea să fie necesar să te reprogramezi. Cel mai important - vei avea nevoie de o configurație .xcodebuild, care să facă referire la fișierele necesare, iar cheia de legătură trebuie să fie disponibilă pe computerul de construire pentru utilizatorul sub numele căruia rulează runner. Pentru semnătura digitală folosim fastlane, iar dacă există probleme sau vrei să afli mai multe, studiază documentația lor detaliată. .
În acest exemplu, folosesc o abordare , dar pentru aplicarea reală, probabil că este mai bine să folosească .
Pregătirea GitLab și fastlane
Pregătirea CI Runner
După ce am adunat toate aceste date, trecem la configurarea GitLab Runner pe dispozitivul MacOS. Din păcate, aplicarea iOS poate fi realizată realmente doar în MacOS. Dar totul se poate schimba, iar dacă așteptați progrese în acest domeniu, - urmăriți proiectele, cum ar fi și , și sarcina noastră internă .
Configurația runner-ului este foarte simplă. Urmați .
Notă. Runner-ul trebuie să utilizeze programul executabil shell. Acest lucru este obligatoriu pentru a construi iOS în macOS, pentru a funcționa direct ca utilizator, nu prin containere. Dacă utilizați shell, compilarea și testarea se efectuează în numele utilizatorului runner-ului, direct pe gazda de compilare. Aceasta nu este la fel de sigură ca containerele, așa că ar fi mai bine să consultați , pentru a nu pierde nimic.
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 startKeychain-ul Apple trebuie să fie configurat pe această gazdă, cu acces la cheile de care are nevoie Xcode pentru a construi. Cea mai simplă metodă de testare este să te conectezi ca utilizator care va iniția compilarea și să încerci să efectuezi compilarea manual. Dacă sistemul solicită acces la keychain, alege „Întotdeauna permiteți” pentru ca CI să funcționeze. Poate ar fi bine să te conectezi și să observi primele câteva pipeline-uri, - asigurându-te că nu mai cer keychain. Problema este că Apple nu ne simplifică munca în mod automat, dar odată ce o configurezi, totul va fi în regulă.
fastlane init
Pentru a utiliza fastlane în proiect, rulează fastlane init. Doar urmează , în special în secțiunea despre , deoarece avem nevoie de o lansare rapidă și previzibilă printr-un pipeline CI automatizat.
În directorul proiectului, rulează aceste comenzi:
xcode-select --install
sudo gem install fastlane -NV
# Alternativ folosind Homebrew
# brew cask install fastlane
fastlane initfastlane va solicita o configurare de bază și apoi va crea în proiect un folder fastlane cu trei fișiere:
1. fastlane/Appfile
Aici nu este nimic complicat. Verifică doar că Apple ID și ID-ul aplicației sunt specificate corect.
app_identifier("com.vontrance.flappybird") # Identificatorul pachetului aplicației tale
apple_id("your-email@your-domain.com") # Adresa ta de email Apple2. fastlane/Fastfile
Fastfile definește pașii de construcție. Folosim multe funcționalități încorporate în fastlane, așa că totul este clar aici. Creăm o linie care obține certificatele, realizează construcția și o încarcă în TestFlight. Poți să împărți acest proces în sarcini diferite, dacă este necesar. Toate aceste operațiuni (get_certificates, get_provisioning_profile, gym și upload_to_testflight) sunt deja incluse în fastlane.
Acțiuni get_certificates și get_provisioning_profile sunt legate de abordarea semnării . Dacă folosești sau altceva, fă modificările necesare.
default_platform(:ios)
platform :ios do
desc "Construiește aplicația"
lane :flappybuild do
get_certificates
get_provisioning_profile
gym
upload_to_testflight
end
end3. fastlane/Gymfile
Acesta este un fișier opțional, dar l-am creat manual pentru a modifica directorul de ieșire implicit și a plasa ieșirile în folderul curent. Acest lucru simplifică CI. Dacă ești interesat, citește despre gym și parametrii săi în .
https://docs.fastlane.tools/actions/gym/Al nostru .gitlab-ci.yml
Deci, avem un CI-runner pentru proiect și suntem gata să testăm pipeline-ul. Să vedem ce avem în .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.ipaTotul este excelent! , folosim strategia clone cu programul de executare shell, pentru a avea un spațiu de lucru curat pentru fiecare construcție și pur și simplu invocăm flappybuild fastlane, așa cum se vede mai sus. La final, obținem construcția, semnătura și desfășurarea ultimei construcții în TestFlight.
De asemenea, obținem artefactul și îl păstrăm împreună cu construcția. Observă că formatul .ipa — este un fișier executabil ARM semnat, care nu poate fi rulat pe simulator. Dacă vrei ieșirile pentru simulator, adaugă pur și simplu ținta de construcție care o produce, apoi include-o în calea artefactului.
Alte variabile de mediu
Aici sunt câteva variabile de mediu pe care se bazează totul.
FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD și FASTLANE_SESSION
Pentru autentificarea în App Store și încărcarea în TestFlight, este necesară autentificarea pentru fastlane. Pentru aceasta, creează o parolă specifică aplicației care va fi folosită în CI. Detalii .
Dacă ai autentificare cu doi factori, creează o variabilă FASTLANE_SESSION (instrucțiunile sunt acolo).
FASTLANE_USER și FASTLANE_PASSWORD
Pentru a am invocat profilul de inițializare și certificatele la cerere, trebuie să definești variabile FASTLANE_USER și FASTLANE_PASSWORD. Detalii . Aceasta nu este necesară dacă folosești o altă metodă de semnare.
În concluzie
Vezi cum funcționează totul .
Sper că a fost util și că te-am inspirat să lucrezi cu build-urile iOS în proiectul GitLab. Iată câteva pentru fastlane, în caz că vrei să folosești CI_BUILD_ID (pentru build-uri incrementale), pentru a .
O altă caracteristică interesantă a fastlane este pentru App Store, care sunt foarte ușor de configurat.
Spune-ne în comentarii despre experiența ta și împărtășește idei pentru îmbunătățirea GitLab pentru dezvoltarea aplicațiilor iOS.
Sursa: habr.com
