Azure Pipeline 캐시 Swift Package Manager가 관리하는 라이브러리 소스 코드

Azure Pipeline을 사용하여 CI 구축, 캐시 Swift Package Manager(SPM)가 관리하는 라이브러리를 원합니다.XCFramework를 사용하지 않으면 구축 시간을 줄일 수 없지만, 비망록으로 프로그램 라이브러리의 원본 코드의 캐시 방법을 보존합니다.

주의 사항

소스 코드는 SPM에서 캐시할 수 있지만 현재 구축된 바이너리는 캐시할 수 없습니다.

이 구축 시간을 줄이려면 구축된 바이너리 캐시가 효과가 있을 것이다[1].

Carrthage(>=0.37.0) 등 의존 라이브러리를 구축한 XCFramework를 통해 S3 또는 Cloud Storage 등에서 획득할 수 있다.

또는 라이브러리 공급자가 XCFramework를 제공한 경우 사용합니다.

Firebase-ios-sdk 등에 속한다.

Azure pipeline의 무료 상자를 대략적으로 검증하기 위해 마이크로소프트 호스트의 건축용 에이전트가 아니라self-hosted 에이전트[2]를 사용한다.지난해 여름 새 조직의 무료 테두리가 허가제[3]로 바뀌었기 때문이다.self-hosted 에이전트는 이 제한의 영향을 받지 않기 때문에 self-hosted 에이전트를 사용했습니다.

샘플 코드

의존 라이브러리는 Firebase-ios-sdk만 추가되어 응용 프로그램으로HelloWorld만 표시됩니다.
https://github.com/Niccari/azure-pipeline-spm-caching
이 코드의 설정은 다음과 같다.

구축 목표: 아이폰(iOS) iOS만 15이상

구축 모드: DevelopDebug

Pipeline 제작용yaml

아래와 같다.테스트 코드라서 서명이 없어요.위에서 말한 바와 같이self-hosted 에이전트를 사용하기 때문에pool은 이 에이전트를 사용하는 에이전트를 지정했습니다.

trigger:
- main
pr: none

pool: SPMCacheBuildAgentPool

variables:
- name: AppName
  value: 'AzurePipelineSPMCaching'
- name: SchemeName
  value: 'DevelopDebug'
- name: SPMResolvedPath
  value: 'AzurePipelineSPMCaching.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved'
- name: CachePath
  value: 'SPMSourcePackages/'

steps:
- task: Cache@2
  inputs:
    key: '"spm" | "$(Agent.OS)" | $(SPMResolvedPath)'
    path: '$(CachePath)'
    restoreKeys: |
      spm | "$(Agent.OS)"
  displayName: Cache SPM packages

- task: Xcode@5
  inputs:
    actions: 'build'
    sdk: 'iphoneos'
    scheme: ${{ variables.SchemeName }}
    xcWorkspacePath: 'AzurePipelineSPMCaching.xcodeproj/project.xcworkspace'
    exportPath:  '$(Build.ArtifactStagingDirectory)'
    args: '-clonedSourcePackagesDirPath $(CachePath)'

캐시 설정

1. 캐시 위치 지정

Cache@2작업의 inputs입니다.path에서 캐시할 디렉터리를 지정합니다.Xcode@5에서 만들 때,args는 프로그램 라이브러리에 의존하는 원본 코드를pull로 지정하는 args-clonedSourcePackagesDirPath $(CachePath)를 지정합니다.

2. 캐시 기준 지정

SPM의 라이브러리 관리는 (アプリ名).xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved 파일로 수행됩니다.따라서 파일을Cache@2작업 키의 끝을 지정합니다.Pipeline 실행 시 Package가 제공됩니다.resolve에 차이가 있으면 캐시가 업데이트됩니다.

소스 코드 캐시가 없는 구축 시간 차이

캐시 시간은 12분 24초, 캐시 시간은 17분 53초입니다.구축 시간이 확실히 줄어들었지만 캐시를 얻는 시간은 이것보다 더 오래 걸린다.건물 시간 단축이 70초 안팎에 머물면서 현금 취득을 1분 정도 통제해도 별 차이가 없기 때문이다.
캐시 상태
캐시 확보 시간 [초]
구축 시간[초]
캐시 생성 시간 [초]
합계 [초]
캐시 해제
4
566
161
744
캐시 있음
564
495
4
1073

비고:Firebase 라이브러리가 XCFramework에서 import일 때 어떻게 되는지

공식 XCFramework 제공가 생성되었습니다.상기 샘플 코드의feature/usebinary_Firebase 분기는 이 코드입니다.구축 시간은 다음과 같습니다.
캐시 상태
캐시 확보 시간 [초]
구축 시간[초]
캐시 생성 시간 [초]
합계 [초]
캐시 해제
4
566
161
744
캐시 있음
564
495
4
1073
XCFramework 사용
0
13
0
30
압도적으로 빠르다.하지만 다음과 같은 과제가 있다.

XCFramework

를 직접 관리해야 함

XCFramework 간에 동일한 XCFramework를 사용할 경우 종속 관계를 스스로 해결해야 함

Firebase의 경우 GTM Session Fetcher를 준수합니다.두 판본은 모두 같은 이진 판본이므로 앞으로 일치하지 않을 때 어떻게 해야 할지 연구해야 한다.

따라서 커트라이트를 사용할지 스스로 관리할지 검토할 필요가 있다.
각주
CI용 SwiftPM 캐시 고려 ↩︎
Azure DevOps로 Self-hosted 환경을 구축하는 방법 ↩︎
Azure Piperlines에 대한 무료 라이센스 변경 ↩︎