Cum GitLab cu fastlane colectează, semnează și publică aplicații iOS în App Store.
Am avut recent cu GitLab și . Aici vom vedea cum să construim și să rulăm o aplicație iOS și să o publicăm în TestFlight. Vezi cat de misto este , iau ansamblul și primesc o actualizare la versiunea de test a aplicației pe același iPad Pro unde am dezvoltat-o.
Aici vom lua , cu care am înregistrat videoclipul.
Câteva cuvinte despre configurația Apple Store
Vom avea nevoie de o aplicație App Store, certificate de distribuție și un profil de furnizare pentru a lega totul.
Cel mai dificil lucru aici este configurarea drepturilor de semnare în App Store. Sper că poți să-ți dai seama singur. Dacă sunteți nou, vă voi îndruma în direcția corectă, dar nu vom vorbi aici despre complexitatea gestionării certificatelor Apple și ele se schimbă constant. Această postare vă va ajuta să începeți.
Aplicatiile mele
Aveți nevoie de o aplicație în App Store Connect, astfel încât să aveți un ID pentru configurare .xcodebuild. Profilul și ID-ul aplicației combină versiunile de cod, prețurile și disponibilitatea și configurația TestFlight pentru distribuirea aplicațiilor de testare către utilizatori. Nu faceți testare publică, testarea privată va fi suficientă dacă aveți un grup mic, o configurare ușoară și nu aveți nevoie de permisiuni suplimentare de la Apple.
Profil de inițializare
Pe lângă configurarea aplicației, aveți nevoie de chei de distribuție și dezvoltare iOS create în secțiunea Certificate, Identificatori și Profiluri din consola Apple Developer. Toate aceste certificate pot fi combinate într-un profil de furnizare.
Utilizatorii care vor fi autentificați trebuie să poată crea certificate, în caz contrar pașii vei vedea o eroare.
alte opțiuni
Pe lângă această metodă simplă, există și alte modalități de a configura certificate și profiluri. Deci, dacă lucrezi diferit, s-ar putea să fii nevoit să te adaptezi. Cel mai important lucru este că aveți nevoie de configurare .xcodebuild, care va indica fișierele necesare, iar brelocul trebuie să fie disponibil pe computerul de construcție pentru utilizatorul sub numele căruia rulează alergătorul. Pentru semnătura digitală folosim fastlane, iar dacă există probleme sau doriți să aflați mai multe, verificați detaliile acestora .
În acest exemplu, folosesc abordarea , dar pentru utilizare reală este probabil mai potrivit .
Se pregătește GitLab și Fastlane
Pregătirea CI Runner
După ce am colectat toate aceste date, trecem la configurarea rulerului GitLab pe dispozitivul MacOS. Din păcate, puteți face numai aplicații iOS pe MacOS. Dar totul se poate schimba, iar dacă te aștepți la progrese în acest domeniu, fii cu ochii pe proiecte precum и , și sarcina noastră internă .
Configurarea alergătorului este foarte simplă. Urmăriți curentul .
Notă. Runnerul trebuie să folosească un program executabil shell. Acest lucru este necesar pentru a construi iOS pe macOS pentru a funcționa direct ca utilizator, mai degrabă decât prin containere. Dacă utilizați shell, construirea și testarea sunt efectuate ca utilizator runner, direct pe gazda de compilare. Nu este la fel de sigur ca containerele, așa că mai bine răsfoiți ca sa nu ratezi 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 startApple Keychain trebuie configurat pe această gazdă cu acces la cheile pe care Xcode trebuie să le construiască. Cel mai simplu mod de a testa acest lucru este să vă conectați ca utilizator care va rula construcția și să încercați să o construiți manual. Dacă sistemul solicită acces la breloc, selectați Permiteți întotdeauna ca CI să funcționeze. Ar putea merita să intri și să urmărești primele două conducte pentru a te asigura că nu mai cer brelocul. Problema este că Apple nu ne face ușor să folosim modul Auto, dar odată ce îl porniți, totul va fi bine.
fastlane init
Pentru a utiliza Fastlane într-un proiect, rulați fastlane init. Doar urmareste , mai ales in sectiunea despre , deoarece avem nevoie de o lansare rapidă și previzibilă printr-o conductă CI automatizată.
În directorul de proiect, rulați aceste comenzi:
xcode-select --install
sudo gem install fastlane -NV
# Alternatively using Homebrew
# brew cask install fastlane
fastlane initfastlane va cere o configurație de bază și apoi va crea un folder fastlane în proiect cu trei fișiere:
1. fastlane/Appfile
Nu e nimic complicat aici. Doar asigurați-vă că ID-ul dvs. Apple și ID-ul aplicației sunt corecte.
app_identifier("com.vontrance.flappybird") # The bundle identifier of your app
apple_id("[email protected]") # Your Apple email address2. fastlane/Fastfile
Fastfile definește etapele de construcție. Folosim o mulțime de funcții încorporate ale Fastlane, așa că totul este clar și aici. Creăm o linie care primește certificate, realizează asamblarea și o încarcă în TestFlight. Puteți împărți acest proces în diferite sarcini dacă este necesar. Toate aceste operațiuni (get_certificates, get_provisioning_profile, gym и upload_to_testflight) sunt deja incluse în Fastlane.
Activitate get_certificates и get_provisioning_profile legate de abordarea semnării . Dacă utilizați sau orice altceva, faceți modificări.
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
Acesta este un fișier opțional, dar l-am creat manual pentru a schimba directorul de ieșire implicit și pentru a plasa rezultatul în folderul curent. Acest lucru simplifică CI. Dacă sunteți interesat, citiți 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 conducta. Să vedem ce avem înăuntru .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.ipaTot excelent! , folosește strategia clone cu programul de execuție shell, astfel încât să avem un spațiu de lucru curat pentru fiecare ansamblu și pur și simplu sunăm flappybuild Fastlane, așa cum se vede mai sus. Ca rezultat, obținem asamblarea, semnătura și implementarea celui mai recent ansamblu în TestFlight.
Primim și artefactul și îl salvăm împreună cu ansamblul. Vă rugăm să rețineți că formatul .ipa este un executabil ARM semnat care nu rulează în simulator. Dacă doriți rezultate pentru simulator, adăugați doar ținta de construcție care o produce și apoi includeți-o în calea artefactului.
Alte variabile de mediu
Există câteva variabile de mediu aici care fac totul să funcționeze.
FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD и FASTLANE_SESSION
Autentificarea pentru fastlane este necesară pentru a se autentifica în App Store și a încărca în TestFlight. Pentru a face acest lucru, creați o parolă pentru aplicația care va fi utilizată în CI. Detalii .
Dacă aveți autentificare cu doi factori, creați o variabilă FASTLANE_SESSION (instrucțiuni acolo).
FASTLANE_USER и FASTLANE_PASSWORD
Că numit profilul de inițializare și certificate la cerere, trebuie să setați variabilele FASTLANE_USER и FASTLANE_PASSWORD. Detalii . Acest lucru nu este necesar dacă utilizați o altă metodă de semnare.
în concluzie
Puteți vedea cum funcționează totul .
Sper că acest lucru a fost util și v-a inspirat să lucrați cu versiuni iOS într-un proiect GitLab. Iată altul pentru fastlane, pentru orice eventualitate. Poate doriți să utilizați CI_BUILD_ID (pentru versiuni incrementale) to .
O altă caracteristică cool a Fastlane este pentru App Store, care sunt foarte ușor de configurat.
Spuneți-ne în comentarii despre experiența dvs. și împărtășiți-vă ideile pentru îmbunătățirea dezvoltării aplicației GitLab pentru iOS.
Sursa: www.habr.com