Ciągła integracja (CI)
Aby korzystać z rejestru w CI, należy upewnić się, że zalogowano się do rejestru, uruchamiając tuist registry login jako część przepływu pracy.
TYLKO INTEGRACJA XCODE
Utworzenie nowego wstępnie odblokowanego pęku kluczy jest wymagane tylko w przypadku korzystania z integracji pakietów w Xcode.
Ponieważ dane uwierzytelniające rejestru są przechowywane w pęku kluczy, należy zapewnić dostęp do pęku kluczy w środowisku CI. Niektórzy dostawcy CI lub narzędzia do automatyzacji, takie jak Fastlane, już tworzą tymczasowy keychain lub zapewniają wbudowany sposób jego tworzenia. Można go jednak również utworzyć, tworząc niestandardowy krok z następującym kodem:
bash
TMP_DIRECTORY=$(mktemp -d)
KEYCHAIN_PATH=$TMP_DIRECTORY/keychain.keychain
KEYCHAIN_PASSWORD=$(uuidgen)
security create-keychain -p $KEYCHAIN_PASSWORD $KEYCHAIN_PATH
security set-keychain-settings -lut 21600 $KEYCHAIN_PATH
security default-keychain -s $KEYCHAIN_PATH
security unlock-keychain -p $KEYCHAIN_PASSWORD $KEYCHAIN_PATHtuist registry login zapisze dane uwierzytelniające w domyślnym pęku kluczy. Upewnij się, że domyślny keychain został utworzony i odblokowany przed uruchomieniem tuist registry login.
Dodatkowo należy upewnić się, że ustawiona jest zmienna środowiskowa TUIST_CONFIG_TOKEN. Można ją utworzyć, postępując zgodnie z dokumentacją
Przykładowy przepływ pracy dla GitHub Actions mógłby wyglądać następująco:
yaml
name: Build
jobs:
build:
steps:
- # Your set up steps...
- name: Create keychain
run: |
TMP_DIRECTORY=$(mktemp -d)
KEYCHAIN_PATH=$TMP_DIRECTORY/keychain.keychain
KEYCHAIN_PASSWORD=$(uuidgen)
security create-keychain -p $KEYCHAIN_PASSWORD $KEYCHAIN_PATH
security set-keychain-settings -lut 21600 $KEYCHAIN_PATH
security default-keychain -s $KEYCHAIN_PATH
security unlock-keychain -p $KEYCHAIN_PASSWORD $KEYCHAIN_PATH
- name: Log in to the Tuist Registry
env:
TUIST_CONFIG_TOKEN: ${{ secrets.TUIST_CONFIG_TOKEN }}
run: tuist registry login
- # Your build stepsRozdzielczość przyrostowa w różnych środowiskach
Czyste/zimne rozdzielczości są nieco szybsze dzięki naszemu rejestrowi, a możesz doświadczyć jeszcze większej poprawy, jeśli utrzymasz rozwiązane zależności w kompilacjach CI. Należy pamiętać, że dzięki rejestrowi rozmiar katalogu, który należy przechowywać i przywracać, jest znacznie mniejszy niż bez rejestru, co zajmuje znacznie mniej czasu. Aby buforować zależności podczas korzystania z domyślnej integracji pakietów Xcode, najlepszym sposobem jest określenie niestandardowej clonedSourcePackagesDirPath podczas rozwiązywania zależności za pośrednictwem xcodebuild. Można to zrobić, dodając następujące elementy do pliku Config.swift:
swift
import ProjectDescription
let config = Config(
generationOptions: .options(
additionalPackageResolutionArguments: ["-clonedSourcePackagesDirPath", ".build"]
)
)Dodatkowo należy znaleźć ścieżkę do Package.resolved. Ścieżkę można uzyskać, uruchamiając ls **/Package.resolved. Ścieżka powinna wyglądać mniej więcej tak: App.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved.
W przypadku pakietów Swift i integracji opartej na XcodeProj możemy użyć domyślnego katalogu .build znajdującego się w katalogu głównym projektu lub w katalogu Tuist. Upewnij się, że ścieżka jest poprawna podczas konfigurowania potoku.
Oto przykładowy przepływ pracy dla GitHub Actions do rozwiązywania i buforowania zależności podczas korzystania z domyślnej integracji pakietów Xcode:
yaml
- name: Restore cache
id: cache-restore
uses: actions/cache/restore@v4
with:
path: .build
key: ${{ runner.os }}-${{ hashFiles('App.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved') }}
- name: Resolve dependencies
if: steps.cache-restore.outputs.cache-hit != 'true'
run: xcodebuild -resolvePackageDependencies -clonedSourcePackagesDirPath .build
- name: Save cache
id: cache-save
uses: actions/cache/save@v4
with:
path: .build
key: ${{ steps.cache-restore.outputs.cache-primary-key }}