Come GitLab con fastlane raccoglie, firma e pubblica applicazioni iOS sull'App Store.
Abbiamo avuto di recente con GitLab e . Qui vedremo come creare ed eseguire un'app iOS e pubblicarla su TestFlight. Scopri quanto è bello , prendo l'assemblaggio e ottengo un aggiornamento alla versione di prova dell'applicazione sullo stesso iPad Pro su cui l'ho sviluppata.
Qui prenderemo , con il quale ho registrato il video.
Qualche parola sulla configurazione dell'Apple Store
Avremo bisogno di un'app App Store, di certificati di distribuzione e di un profilo di provisioning per collegare tutto insieme.
La cosa più difficile qui è impostare i diritti di firma nell'App Store. Spero che tu possa capirlo da solo. Se sei nuovo, ti indicherò la giusta direzione, ma qui non parleremo delle complessità della gestione dei certificati Apple e sono in costante cambiamento. Questo post ti aiuterà a iniziare.
Le mie applicazioni
Hai bisogno di un'app in App Store Connect per avere un ID per la configurazione .xcodebuild. Il profilo e l'ID dell'applicazione combinano build di codice, prezzi e disponibilità e configurazione TestFlight per la distribuzione delle applicazioni di test agli utenti. Non eseguire test pubblici, i test privati saranno sufficienti se hai un piccolo gruppo, una configurazione semplice e non hai bisogno di autorizzazioni aggiuntive da parte di Apple.
Profilo di inizializzazione
Oltre alla configurazione dell'app, sono necessarie le chiavi di distribuzione e sviluppo iOS create nella sezione Certificati, identificatori e profili della console Apple Developer. Tutti questi certificati possono essere combinati in un profilo di provisioning.
Gli utenti che verranno autenticati devono essere in grado di creare certificati, altrimenti i passaggi vedrai un errore.
altre opzioni
Oltre a questo semplice metodo, esistono altri modi per configurare certificati e profili. Quindi, se lavori diversamente, potresti dover adattarti. La cosa più importante è che hai bisogno di configurazione .xcodebuild, che indicherà i file necessari e il portachiavi deve essere disponibile sul computer di creazione per l'utente sotto il cui nome sta correndo il corridore. Per la firma digitale utilizziamo fastlane, e se ci sono problemi o vuoi saperne di più controlla i loro dettagli .
In questo esempio sto utilizzando l'approccio , ma per l'uso reale probabilmente è più adatto .
Preparazione GitLab e fastlane
Preparazione del corridore CI
Raccolti tutti questi dati, passiamo alla configurazione del runner GitLab sul dispositivo macOS. Sfortunatamente, puoi creare app iOS solo su MacOS. Ma tutto può cambiare e, se ti aspetti progressi in questo settore, tieni d'occhio progetti come и e il nostro compito interno .
Configurare il runner è molto semplice. Segui la corrente .
Nota. Il corridore deve utilizzare un programma eseguibile shell. Ciò è necessario per creare iOS su macOS in modo che funzioni direttamente come utente anziché tramite contenitori. Se stai usando shell, la creazione e il test vengono eseguiti come utente runner, direttamente sull'host di compilazione. Non è sicuro come i contenitori, quindi è meglio navigare così non ti perdi nulla.
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 startIl portachiavi Apple deve essere configurato su questo host con accesso alle chiavi necessarie per la creazione di Xcode. Il modo più semplice per testarlo è accedere come utente che eseguirà la build e provare a crearla manualmente. Se il sistema richiede l'accesso al portachiavi, seleziona Consenti sempre il funzionamento dell'interfaccia CI. Potrebbe valere la pena entrare e osservare le prime due condutture per assicurarsi che non chiedano più il portachiavi. Il problema è che Apple non ci semplifica l'uso della modalità automatica, ma una volta avviata, tutto andrà bene.
corsia veloce init
Per utilizzare fastlane in un progetto, esegui fastlane init. Segui e basta , soprattutto nella sezione su , perché abbiamo bisogno di un lancio rapido e prevedibile attraverso una pipeline CI automatizzata.
Nella directory del tuo progetto, esegui questi comandi:
xcode-select --install
sudo gem install fastlane -NV
# Alternatively using Homebrew
# brew cask install fastlane
fastlane initfastlane chiederà una configurazione di base e poi creerà una cartella fastlane nel progetto con tre file:
1. fastlane/Appfile
Non c'è niente di complicato qui. Assicurati solo che il tuo ID Apple e l'ID app siano corretti.
app_identifier("com.vontrance.flappybird") # The bundle identifier of your app
apple_id("[email protected]") # Your Apple email address2. fastlane/Fastfile
Fastfile definisce le fasi di creazione. Utilizziamo molte funzionalità integrate di Fastlane, quindi anche qui tutto è chiaro. Creiamo una riga che riceve i certificati, esegue l'assemblaggio e lo carica su TestFlight. Se necessario, è possibile dividere questo processo in diverse attività. Tutte queste operazioni (get_certificates, get_provisioning_profile, gym и upload_to_testflight) sono già inclusi in fastlane.
Attività get_certificates и get_provisioning_profile legati all’approccio della firma . Se stai usando o qualsiasi altra cosa, apportare modifiche.
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
Questo è un file facoltativo, ma l'ho creato manualmente per modificare la directory di output predefinita e posizionare l'output nella cartella corrente. Ciò semplifica la CI. Se interessato, leggi gym e i suoi parametri in .
https://docs.fastlane.tools/actions/gym/Il nostro .gitlab-ci.yml
Quindi, abbiamo un corridore CI per il progetto e siamo pronti per testare la pipeline. Vediamo cosa abbiamo dentro .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.ipaTutto va bene! , usa la strategia clone con il programma in esecuzione shell, in modo da avere uno spazio di lavoro pulito per ogni assembly e chiamare semplicemente flappybuild corsia veloce, come visto sopra. Di conseguenza, otteniamo l'assemblaggio, la firma e la distribuzione dell'ultimo assembly in TestFlight.
Otteniamo anche l'artefatto e lo salviamo con l'assembly. Si prega di notare che il formato .ipa è un eseguibile ARM firmato che non viene eseguito nel simulatore. Se desideri l'output per il simulatore, aggiungi semplicemente la destinazione di build che lo produce e quindi includilo nel percorso dell'artefatto.
Altre variabili d'ambiente
Ci sono un paio di variabili d'ambiente qui che fanno funzionare tutto.
FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD и FASTLANE_SESSION
L'autenticazione per Fastlane è necessaria per autenticarsi nell'App Store e caricare su TestFlight. A tale scopo, creare una password per l'applicazione che verrà utilizzata in CI. Dettagli .
Se disponi dell'autenticazione a due fattori, crea una variabile FASTLANE_SESSION (istruzioni lì).
FASTLANE_USER и FASTLANE_PASSWORD
Che chiamato profilo di inizializzazione e certificati su richiesta, è necessario impostare le variabili FASTLANE_USER и FASTLANE_PASSWORD. Dettagli . Ciò non è necessario se si utilizza un metodo di firma diverso.
insomma
Puoi vedere come funziona il tutto .
Spero che questo sia stato utile e ti abbia ispirato a lavorare con le build iOS in un progetto GitLab. Eccone un altro per fastlane, per ogni evenienza. Potresti voler usare CI_BUILD_ID (per build incrementali) a .
Un'altra caratteristica interessante di Fastlane è per l'App Store, che sono molto facili da configurare.
Raccontaci nei commenti la tua esperienza e condividi le tue idee per migliorare lo sviluppo di app GitLab per iOS.
Fonte: habr.com