Xcode ქეში

Tuist უზრუნველყოფს Xcode-ის კომპილაციის ქეშის მხარდაჭერას, რაც გუნდებს საშუალებას აძლევს გაუზიარონ კომპილაციის არტეფაქტები ბილდ სისტემის ქეშირების შესაძლებლობების გამოყენებით.

Xcode ქეში წარმოდგენილი იქნა Xcode 26-ში. მას ასევე შეგიძლიათ ნახოთ როგორც Xcode ბილდ ქეში; ის ხელახლა იყენებს კომპილაციის არტეფაქტებს, რომლებიც დაკავშირებულია მათ შემავალ მონაცემებთან, ხოლო Tuist-ის დისტანციური ქეში ამ არტეფაქტების გაზიარებას ახდენს სხვადასხვა მანქანებს შორის.

გააერთიანეთ მოდულის ქეშთან

Xcode ქეში და მოდულის ქეში მუშაობენ სხვადასხვა დეტალიზაციის დონეზე და ერთმანეთს ავსებენ. მოდულის ქეში ცვლის მთლიან მოდულებს წინასწარ აგებული .xcframework-ებით ბილდის დაწყებამდე, ხოლო Xcode ქეში ხელახლა იყენებს კომპილაციის შედეგებს ბილდის პროცესში.

დეველოპერის მანქანებზე, შეინახეთ CompilationCache.noindex გასუფთავებისას

ნაგულისხმევად, კომპილაციის ქეშის საცავი მდებარეობს DerivedData-ში, ამიტომ DerivedData-ის წაშლა მასთან ერთად შლის ბილდის პროდუქტებსაც. დეველოპერის მანქანაზე, უპირატესობა მიანიჭეთ მხოლოდ ბილდის პროდუქტების წაშლას: გადააგება მაშინ აღდგება დისკზე არსებული საცავიდან, ყოველგვარი ჩამოტვირთვის გარეშე.

მოწყობა#

თუ ჯერ არ გაქვთ Tuist ანგარიში და პროექტი, შეგიძლიათ შექმნათ შემდეგი ბრძანების გაშვებით:

bash

tuist init

როდესაც გექნებათ Tuist.swift ფაილი, რომელიც მიუთითებს თქვენს fullHandle-ზე, შეგიძლიათ მოაწყოთ ქეშირება თქვენი პროექტისთვის შემდეგი ბრძანების გაშვებით:

bash

tuist setup cache

ეს ბრძანება ქმნის LaunchAgent-ს, რათა გაუშვას ლოკალური ქეშის სერვისი სისტემის ჩატვირთვისას, რომელსაც Swift ბილდ სისტემა იყენებს კომპილაციის არტეფაქტების გასაზიარებლად. თავდაპირველად გაუშვით ის თქვენს დეველოპერულ მანქანაზე და CI სამუშაოს მოწყობის ნაწილად.

CI-ზე ქეშის მოსაწყობად, დარწმუნდით, რომ ხართ ავტორიზებული.

ქეშის კომპონენტების განახლება#

ქეშის პროქსი იყენებს სტაბილურ გამშვებს და არა გზას, რომელიც მიბმულია Tuist-ის ინსტალაციაზე, რომელმაც ბოლოს გაუშვა მოწყობა. ინსტალაციის შემდეგ, tuist setup cache და ქეშით აღჭურვილი tuist generate გადაჰყავს გამოყენებად მიზანს Tuist-ის ახალ ვერსიებზე. პროექტები, რომლებიც მიბმულია Tuist-ის ძველ ვერსიაზე, არ აწევს საერთო პროქსის ვერსიას ქვემოთ. გენერაცია მხოლოდ აახლებს არსებულ გამშვებ მიზანს: ის არ აყენებს სერვისს, არ ახდენს ავტორიზაციას, არ ცვლის პლაგინს და არ ა重新启动ებს პროქსის. პლაგინის, პროქსის, სოკეტის ან რეესტრის მორგებული გადაწერები ტოვებენ ავტომატურ განახლებას.

მოქმედი პროქსი იღებს ახალ მიზანს მხოლოდ მაშინ, როდესაც ქეშის მოთხოვნები არ არის მინიმუმ 30 წამის განმავლობაში, არ არის მოთხოვნები ან ფონური სამუშაოები მიმდინარე პროცესში და მისი გამოქვეყნების რიგები დაცლილია. შემდეგ ის ტოვებს პროცესს და launchd იწყებს შერჩეულ CLI-ს, ინარჩუნებს სერვისის არგუმენტებს და სერთიფიკატების გარემოს. მხოლოდ პროქსი, რომელიც რეალურად იღებს მიზანს, ატომურად აახლებს დისკზე არსებულ პლაგინს თავისი ბანდიდან; მოწყობა არ აყენებს ახალ პლაგინს, სანამ ძველი პროქსი ჯერ კიდევ ასუფთავებს რიგებს. თუ ინსტალირებული პლაგინი არ არის, ცალსახა უმოქმედო მოწყობა ა重新启动ებს შერჩეულ პროქსის განახლების თავიდან სცდისთვის. კვლავ მხოლოდ ერთი პროქსი ფლობს რეესტრს და რიგებს. მიუწვდომელი მიზანი ან დაუცლელი ატვირთვები გადადებს გადართვას აქტიური მოთხოვნების შეწყვეტის ნაცვლად. სერთიფიკატების განახლება მიჰყვება შერჩეულ CLI-ს გადართვამდეც კი, ამიტომ ძველი CLI ინსტალაციის წაშლა არ ტოვებს ატვირთვებს რიგში ლოდინში.

არსებული ინსტალაცია, რომელიც შეიქმნა სტაბილური გამშვების წინ, საჭიროებს ერთ ცალსახა მიგრაციას. გაუშვით შემდეგი, როდესაც ბილდები არ მუშაობს:

bash

tuist setup cache

ამ მიგრაციის შემდეგ, Tuist-ის განახლება და ჩვეულებრივი tuist generate-ის გაშვება საკმარისია პროქსისა და ინსტალირებული პლაგინის განახლებისთვის; თქვენ არ გჭირდებათ მოწყობის ხელახლა გაშვება CLI-ის ყოველი ვერსიისთვის. ცალსახა მოწყობა კვლავ საჭიროა სხვა Xcode-ის შერჩევისთვის, მათ შორის იმავე გზაზე განახლებული Xcode-ისთვის. მოწყობას შეუძლია ჩაანაცვლოს საერთო სერვისი, როდესაც მისი კონფიგურაცია იცვლება, ამიტომ ჯერ დაელოდეთ მანქანაზე ყველა ბილდის დასრულებას. პროქსი მხარდაჭერს წინა პლაგინის პროტოკოლსაც და მიმდინარესაც, ამიტომ Xcode-ში უკვე ჩატვირთული თავსებადი პლაგინი განაგრძობს მუშაობას პროქსის განახლების შემდეგაც. სრულად დახურეთ და ხელახლა გახსენით Xcode უახლესი პლაგინის ჩასატვირთად, მაგრამ თავსებადი ჩატვირთული პლაგინი არ საჭიროებს დაუყოვნებელ გადატვირთვას. ხელახლა შექმენით პროექტები, როდესაც ვერსია ცვლის გენერირებულ ბილდის პარამეტრებს.

შეინახეთ შერჩეული Tuist ინსტალაცია ხელმისაწვდომად: გამშვები იყენებს მას ჩატვირთვის, კონფიგურაციისა და სერთიფიკატების განახლებისთვის. ძველი ინსტალაციები შეიძლება წაიშალოს, როდესაც გამშვები განახლდება. თუ შერჩეული შესრულებადი ფაილი წაიშალა ან აღარ არის შესრულებადი, tuist setup cache შეუძლია აღადგინოს მიზანი ხელმისაწვდომი ინსტალაციის გამოყენებით, თუნდაც ძველი ვერსიით, ქეშის წინასწარი გაუქმების გარეშე. სტაბილური შესრულებადი ფაილების ალიასები ინახება პაკეტის მენეჯერის განახლებების დროს; სიმბოლური ბმულები იხსნება მხოლოდ ინსტალაციის იდენტურობის შედარებისას. ჩატვირთვისას პროქსი იწერს რეალურად გაშვებულ ვერსიას, მათ შორის ადგილზე განახლებებს ან განზრახ დაბრუნებებს, თანახმად ინახავს უმაღლეს გამოყენებულ ვერსიას, რათა თავიდან აიცილოს არარელევანტური ძველი კოდების მიერ სასარგებლო ინსტალაციის გადართვა.

წყაროდან აგებული CLI-ები რელიზის ვერსიის გარეშე და ცალსახა TUIST_CAS_PLUGIN_PATH ან TUIST_CAS_PROXY_PATH მოწყობები იყენებენ ცალსახა გაშვების კონფიგურაციას ავტომატური ვერსიის შერჩევის ნაცვლად. ხელახლა გაუშვით მოწყობა ამ კომპონენტების ხელახლა აგების შემდეგ. მოწყობა ამოწმებს მათ ახალგაზრდობას და თიშავს მართვად მიზნის განახლებას მხოლოდ მას შემდეგ, რაც მისი ჩამნაცვლებელი მზად იქნება.

tuist teardown cache აჩერებს სერვისს გამშვები მიზნის წაშლამდე, თანახმად ინარჩუნებს სტაბილურ პლაგინს არსებული პროექტებისთვის. თუ სერვისის გაჩერება ვერ მოხერხდა, მისი გამშვები რჩება ხელმისაწვდომი გადატვირთვისა და კიდევ ერთი გაუქმების მცდელობისთვის. გენერაცია ვერ აღადგენს სერვისს წარმატებული გაუქმების შემდეგ.

Xcode ბილდის პარამეტრების კონფიგურაცია#

არსებული Xcode პროექტისთვის, გადაწერეთ ბილდის პარამეტრები, რომლებსაც ბეჭდავს tuist setup cache, თქვენი პროექტის Build Settings-ში ან არსებულ .xcconfig ფაილში. ბრძანება ბეჭდავს კონფიგურაციას თქვენი ანგარიშისთვის; ის არ ქმნის კონფიგურაციის ფაილს და არ არედაქტირებს თქვენს Xcode პროექტს. შეინახეთ $(inherited), როდესაც აფართოებთ OTHER_SWIFT_FLAGS-ს, რათა სხვა კომპილატორის ოფციები შენარჩუნდეს.

პარამეტრები მოიცავს:

bash

COMPILATION_CACHE_ENABLE_CACHING = YES
COMPILATION_CACHE_ENABLE_PLUGIN = YES
COMPILATION_CACHE_PLUGIN_PATH = $HOME/.local/state/tuist/libtuist_cas_plugin.dylib
COMPILATION_CACHE_REMOTE_SERVICE_PATH = $HOME/.local/state/tuist/cas-proxy.sock
COMPILATION_CACHE_ENABLE_DETACHED_KEY_QUERIES = YES
COMPILATION_CACHE_ENABLE_DIAGNOSTIC_REMARKS = YES
OTHER_SWIFT_FLAGS = $(inherited) -cas-plugin-option tuist-instance=your-org/your-project

გაითვალისწინეთ, რომ COMPILATION_CACHE_ENABLE_PLUGIN, COMPILATION_CACHE_PLUGIN_PATH, COMPILATION_CACHE_REMOTE_SERVICE_PATH და COMPILATION_CACHE_ENABLE_DETACHED_KEY_QUERIES უნდა დაემატოს როგორც მომხმარებლის მიერ განსაზღვრული ბილდის პარამეტრები, რადგან ისინი პირდაპირ არ არის ხელმისაწვდომი Xcode-ის ბილდის პარამეტრების UI-ში.

პლაგინის გზა

libtuist_cas_plugin.dylib არის კომპილაციის ქეშის პლაგინი, რომელიც მოყვება Tuist-ს, tuist შესრულებადი ფაილის გვერდით. tuist setup cache ასკოპირებს მას $HOME/.local/state/tuist/libtuist_cas_plugin.dylib-ში და COMPILATION_CACHE_PLUGIN_PATH მიუთითებს ამ ასლზე. გზა იგივეა ყველა მანქანაზე და არ იცვლება Tuist-ის განახლებისას, ამიტომ შეგიძლიათ ეს პარამეტრი თქვენს პროექტთან ერთად დააკომიტოთ. Setup და ახლად გაშვებული პროქსი ანახლებენ ასლს შერჩეული Tuist ბანდლიდან; ძველი ჩექაუტიდან setup-ის გაშვება არ აწევს უფრო ახალ პლაგინს.

ერთი სოკეტი ყოველი პროექტისთვის

tuist setup cache აყენებს ერთ ქეშ პროქსს თითო მანქანაზე, ამიტომ ყოველი პროექტი იყენებს ერთსა და იმავე COMPILATION_CACHE_REMOTE_SERVICE_PATH. tuist-instance პლაგინის ოფციაა ის, რაც პროექტს აიდენტიფიცირებს.

COMPILATION_CACHE_REMOTE_SERVICE_PATH არის ის, რაც C-სა და Objective-C-ს აზიარებს

მარტივია ამ პარამეტრის აღქმა როგორც „სად ცხოვრობს ქეშის სერვისი“ და მისი განხილვა როგორც არასავალდებულოს. ის ასევე არის გადამრთველი, რომელიც წყვეტს, გაზიარდება თუ არა C, Objective-C, წინასწარ კომპილირებული მოდულები და წინასწარ კომპილირებული ჰედერები საერთოდ: ბილდის სისტემა მათთვის ქეშინგს მხოლოდ მაშინ აკეთებს, როცა დისტანციური ქეშის სერვისია კონფიგურირებული. თუ გამოტოვებთ, Swift-ის კომპილაციები მაინც გაზიარდება, მაგრამ ყოველი C/Objective-C ფაილი და ყოველი მოდული ხელახლა კომპილირდება ნებისმიერ მანქანაზე, რომელსაც პროექტი ადრე არ აუწყვია.

პარალელური ქეშის ძიებები

COMPILATION_CACHE_ENABLE_DETACHED_KEY_QUERIES აწარმოებს დისტანციურ ქეშის ძიებებს, რომლებსაც ბილდის სისტემა აკეთებს თითოეული კომპილაციისთვის, ბილდის დანარჩენ პროცესთან ერთად, ნაცვლად იმისა, რომ რამდენიმე ერთდროულად შესრულდეს ბილდის შესრულების ზოლებზე. ბილდები, რომლებიც ბევრ კომპილაციას ვერ პოულობენ ან აღადგენენ შორეული ქეშიდან, უფრო სწრაფად სრულდება.

ასევე შეგიძლიათ მიუთითოთ ეს პარამეტრები xcodebuild-ის გაშვებისას შემდეგი ფლაგების დამატებით, მაგალითად:

bash

xcodebuild build -project YourProject.xcodeproj -scheme YourScheme \
    COMPILATION_CACHE_ENABLE_CACHING=YES \
    COMPILATION_CACHE_ENABLE_PLUGIN=YES \
    COMPILATION_CACHE_PLUGIN_PATH=$HOME/.local/state/tuist/libtuist_cas_plugin.dylib \
    COMPILATION_CACHE_REMOTE_SERVICE_PATH=$HOME/.local/state/tuist/cas-proxy.sock \
    COMPILATION_CACHE_ENABLE_DETACHED_KEY_QUERIES=YES \
    COMPILATION_CACHE_ENABLE_DIAGNOSTIC_REMARKS=YES \
    'OTHER_SWIFT_FLAGS=$(inherited) -cas-plugin-option tuist-instance=your-org/your-project'

პრეფიქსის მეპინგი Xcode 27-ზე და ზემოთ

Xcode 27-ზე და ზემოთ, tuist setup cache ასევე ბეჭდავს SWIFT_ENABLE_PREFIX_MAPPING, SWIFT_ENABLE_PROJECT_PREFIX_MAPPING, CLANG_ENABLE_PREFIX_MAPPING და CLANG_ENABLE_PROJECT_PREFIX_MAPPING-ს. ისინი კომპილაციის ქეშის გასაღებებს დამოუკიდებელს ხდიან იმისგან, თუ სად მდებარეობს პროექტი და DerivedData. დაამატეთ ისინი როგორც მომხმარებლის მიერ განსაზღვრული ბილდის პარამეტრები. მათი ჩართვა ცვლის ყოველ ქეშის გასაღებს, ამიტომ შემდეგი ბილდი ხელახლა ავსებს ქეშს. tuist generate აყენებს მათ თქვენთვის, როცა enableCaching ჩართულია.

კომპილატორი ასევე წერს მეპირებულ გზებს კოდის დაფარვის მონაცემებში და Xcode ვერ აგვარებს მათ, ამიტომ დაფარვის ანგარიში გამოტოვებს ყოველ წყაროს, რომელიც კომპილირებულია პრეფიქსის მეპინგით. დაბეჭდილი პარამეტრები, TUIST_PREFIX_MAPPING_FOR_COVERAGE_* პარამეტრებთან ერთად, თიშავენ პრეფიქსის მეპინგს ბილდებში, რომლებიც აგროვებენ კოდის დაფარვას. tuist generate იგივეს აკეთებს. ეს ბილდები მაინც იყენებენ კომპილაციის ქეშს, მაგრამ მათი ქეშის გასაღებები დამოკიდებულია პროექტისა და DerivedData გზებზე.

როცა ამ პარამეტრებს გადასცემთ xcodebuild-ს კომანდურ ხაზზე, ერთმაგი ბრჭყალებში ჩასვით მნიშვნელობები, რომლებიც შეიცავენ $(...)-ს, როგორც ზემოთ OTHER_SWIFT_FLAGS-ის შემთხვევაში. წინააღმდეგ შემთხვევაში, გარსი მათ ცარიელ სტრინგებად გაშლის და პრეფიქსის მეპინგი გაითიშება:

bash

xcodebuild build -project YourProject.xcodeproj -scheme YourScheme \
    'SWIFT_ENABLE_PREFIX_MAPPING=$(TUIST_PREFIX_MAPPING_FOR_COVERAGE_$(CLANG_COVERAGE_MAPPING))' \
    SWIFT_ENABLE_PROJECT_PREFIX_MAPPING=YES \
    'CLANG_ENABLE_PREFIX_MAPPING=$(TUIST_PREFIX_MAPPING_FOR_COVERAGE_$(CLANG_COVERAGE_MAPPING))' \
    CLANG_ENABLE_PROJECT_PREFIX_MAPPING=YES \
    TUIST_PREFIX_MAPPING_FOR_COVERAGE_=YES \
    TUIST_PREFIX_MAPPING_FOR_COVERAGE_NO=YES \
    TUIST_PREFIX_MAPPING_FOR_COVERAGE_YES=NO

გენერირებული პროექტები

პარამეტრების ხელით დაყენება არ არის საჭირო, თუ თქვენი პროექტი გენერირებულია Tuist-ით.

ამ შემთხვევაში, ყველაფერი, რაც გჭირდებათ, არის enableCaching: true-ის დამატება თქვენს Tuist.swift ფაილში:

swift

import ProjectDescription

let tuist = Tuist(
    fullHandle: "your-org/your-project",
    project: .tuist(
        generationOptions: .options(
            enableCaching: true
        )
    )
)

დაფარვა პრეფიქსის მეპინგით#

ნაგულისხმევად, გენერირებული პროექტები თიშავენ პრეფიქსის მეპინგს დაფარვის ბილდებისთვის, რათა Xcode-ის დაფარვის ანგარიშები და xccov იმუშაონ. შეგიძლიათ ჩართოთ ის, რათა დაფარვის კომპილაციები გაზიარებადი იყოს ჩექაუტებს შორის:

swift

let tuist = Tuist(
    project: .tuist(
        generationOptions: .options(
            enableCaching: true,
            coverage: .coverage(prefixMapping: true)
        )
    )
)

TUIST_COVERAGE_PREFIX_MAPPING გარემოს ცვლადი (1 ან 0) უპირატესობას იღებს prefixMapping-ზე. ეს ოფცია მოქმედებს Xcode 27-ზე და ზემოთ და მოითხოვს enableCaching-ს. დაფარვის tuist test ატვირთვები მას მხარს უჭერენ: Tuist ზომავს გაშვებას llvm-cov-ით, რომელიც კითხულობს წყაროებს მეპირებული გზებით და აბრუნებს მათ თქვენი რეპოზიტორიის ფაილებთან. Xcode-ის საკუთარი დაფარვის ანგარიში და xccov მაინც შეიძლება გამოტოვონ ეს წყაროები, ისევე როგორც ატვირთვამ, რომელიც გადადის შედეგის ბანდლის xccov ანგარიშზე, რადგან llvm-cov ექსპორტი ვერ მოხერხდა. მეპირებულმა #filePath მნიშვნელობებმა ასევე შეიძლება იმოქმედონ ტესტებზე, რომლებიც ფიქსტურებს პოულობენ წყაროს ფაილების მიმართებით; ნაცვლად ამისა, ფიქსტურები გადაწყვიტეთ აშკარა runtime ჩექაუტის გზებით. თუ დაფარვას თავად ამუშავებთ, შეუსაბამეთ თითოეული ინსტრუმენტირებული ბინარი მისი მიზნის $(TARGET_TEMP_DIR)/compilation-prefix-map.json-თან, რომელიც ვირტუალურ პრეფიქსებს აბრუნებს ლოკალურ დირექტორიებთან. არ გამოიყენოთ ერთი მიზნის რუკა ყოველი ბინარისთვის, როცა პროექტის მიხედვით მეპინგია ჩართული.

დაფარვის-პრეფიქსის პარამეტრები მონაწილეობენ ბინარული ქეშისა და სელექციური ტესტირების ჰეშებში, რადგან ისინი აკონტროლებენ დაფარვის არტეფაქტებში ჩაწერილ გზებს. ამ ოფციის შეცვლა, ან TUIST_COVERAGE_PREFIX_MAPPING-ის სხვანაირად დაყენება, არაამოქმედებს ამ ჰეშებს მაშინაც კი, ჩვეულებრივი ბილდებისთვის. შეინარჩუნეთ მნიშვნელობა თანმიმდევრული დეველოპერებსა და CI სამუშაოებს შორის, თუ მათ უნდა გაიზიარონ ბინარული ქეშები და სელექციური ტესტირების შედეგები.

გენერირებული პროექტების დებაგინგი#

აღდგენილ ნეიტიურ მოდულებს სჭირდებათ დაკავშირებული დებაგის ინფორმაცია, ისევე როგორც კომპილაციის ქეშზე წვდომა. Tuist ათბობს Debug და Release მოდულებს dSYM-ებითა და სლაისის მიხედვით წყაროს იდენტურობის მეტამონაცემებით, შემდეგ ამოწმებს მეტამონაცემებს მომხმარებლის მიერ დეკლარირებულ წყაროებთან მიზნის ჩანაცვლებამდე. დაკარგული ან შეუთავსებელი მეტამონაცემები ინარჩუნებს ამ მიზნის წყაროებს. სკრიპტით გენერირებულ .generated(...) წყაროებს აქვთ დეკლარაციის თითის ანაბეჭდები და არა ვერიფიცირებადი შინაარსის ჩექსამები, ამიტომ ეს მიზნები რჩებიან წყაროდან აწყობილი და არ იგზავნებიან ნეიტიური მოდულის ქეშში. გენერირებული რესურსების აქსესორები რეალური შინაარსის ჩექსამებით რჩებიან შესაბამისად. მხარდაუჭერელი დებაგის ინფორმაცია ტოვებს დაზარალებული მიზნის გამოქვეყნებას, მაგრამ არ ბლოკავს არარელევანტურ პროდუქტებს; წყაროს მუტაცია და გაუქმება მაინც აფუჭებს გათბობას. ქეშის ფორმატი იცვლება, ამიტომ ძველი ვერსიებით გათბილ არტეფაქტებს ხელახლა გათბობა სჭირდებათ.

ვერიფიცირებული ჩანაცვლებებისთვის, Tuist ამზადებს წყაროს გადაადგილებებს მომხმარებლის მფლობელობაში არსებულ dSYM UUID plists-ში და აკავშირებს მხოლოდ დებაგის კომპანიონებს სტატიკური ქეშირებული კოდისთვის. ის არ გადაწერს ქეშირებულ ბინარებს და არ აყენებს პროდიუსერის წყაროს გზებს LLDB-ის მუდმივ გლობალურ წყაროს რუკაში. აშკარა დებაგერის ინიციალიზატორები და მოდულის ჩამტვირთავის პარამეტრები რჩებიან ავტორიტეტულად. დებაგის სიმბოლოები და წყაროს გადაადგილება არ აღადგენენ წყაროს მიმართებით runtime ფაილზე წვდომას ან ნეიტიურ Xcode დაფარვის ანგარიშებს; დაფარვის ვარიანტის შერჩევა და LLVM ექსპორტი რჩებიან ცალკეული ფუნქციები.

enableCaching: true-ით, Tuist აკონფიგურირებს LLDB წყაროს რუკებს Run და Test ქმედებებისთვის. როდესაც ქმედებას აქვს მორგებული LLDB ინიციალიზატორი, Tuist ჯერ ჩაწერს მის ამოხსნილ წყაროს რუკას, შემდეგ კი ასრულებს მორგებულ ინიციალიზატორს, რათა მან შეძლოს რუკის გაფართოება ან გადაფარვა. წინააღმდეგ შემთხვევაში, ის ტვირთავს ~/.lldbinit-Xcode-ს, თუ ფაილი არსებობს, ხოლო თუ არა — გადადის ~/.lldbinit-ზე, სანამ წყაროს რუკას ჩაანაცვლებს. ის ტვირთავს მხოლოდ ერთ საწყის ფაილს, აღადგენს მომხმარებლის დებაგერის პარამეტრებს ორმაგი ჩატვირთვის გარეშე. ჩანაცვლება შლის ძველ ასახვებს წინა გაშვებებიდან და ანიჭებს უპირატესობას საწყისი ფაილის წყაროს რუკებს; წყაროს რუკის ის ჩანაწერები, რომლებიც უნდა შენარჩუნდეს, განათავსეთ ქმედების მორგებულ ინიციალიზატორში. სხვა საწყისი პარამეტრები ინარჩუნება. Tuist-ის ქეშისთვის სპეციფიკური მოდულის ძიების გზები, ჩამტვირთავის პარამეტრები და Clang-ის ფლაგები გამოიყენება შემდეგ და ანიჭებს უპირატესობას მომხმარებლის მნიშვნელობებს ამ პარამეტრებისთვის. საწყისი ფაილის შეცდომები რჩება ხილული, რაც არ აჩერებს შემდგომი ბრძანებების ჩატვირთვას, და ბრძანებები არ მეორდება. ეს ინიციალიზატორის შენარჩუნება ვრცელდება მაშინაც, როდესაც Tuist აკონფიგურირებს დებაგინგს მოდულის ქეშიდან აღდგენილი ბინარებისთვის, enableCaching-ის გარეშეც კი და Xcode-ის ადრეულ ვერსიებზე.

Xcode 27-ზე და უფრო ახალ ვერსიებზე, გენერირებული პროექტები ტოვებენ Xcode-ის პროექტის მიხედვით პრეფიქსების ასახვებს (SWIFT_ENABLE_PROJECT_PREFIX_MAPPING და CLANG_ENABLE_PROJECT_PREFIX_MAPPING) გამორთულს, თუ პროექტი მათ არ აყენებს. მათი პრეფიქსები, მაგალითად /^src, თითოეულ პროექტში სხვადასხვა დირექტორიას აღნიშნავს და LLDB მათ აგვარებს მხოლოდ დებაგირებადი სამიზნის პროექტის მიმართ. წყაროები კი ჩაიწერება სამუშაო სივრცის მასშტაბის პრეფიქსებით: /^root Tuist-ის ფესვის დირექტორიისთვის, /^spm Swift პაკეტის დროებითი დირექტორიისთვის, ხოლო /^intermediates და /^products აგების შედეგებისთვის. თითოეული მათგანი თითოეულ პროექტში ერთსა და იმავე დირექტორიას აღნიშნავს, ამიტომ breakpoints ამოიხსნება ნებისმიერი პროექტის წყაროებში სამუშაო სივრცეში.

Tuist-ის ფესვის გარეთ მდებარე გზები არ ასახდება. ფესვის გარეთ მდებარე პროექტის ქეშის გასაღებები დამოკიდებულია იმაზე, თუ სად არის ის checkout-ებული, ამიტომ სხვა checkout-ები და მანქანები ვერ იყენებენ მის ქეშს. იმისთვის, რომ მისი გასაღებები დამოუკიდებელი იყოს checkout-ის ადგილმდებარეობისგან, ჩართეთ პროექტის მიხედვით ასახვები იმ პროექტის manifest-ში:

swift

let checkoutIndependentSettings = Settings.settings(base: [
    "SWIFT_ENABLE_PROJECT_PREFIX_MAPPING": "YES",
    "CLANG_ENABLE_PROJECT_PREFIX_MAPPING": "YES",
])

გადაეცით ეს პარამეტრები იმ Project-ს. როდესაც თქვენ ადებაგებთ სხვა პროექტის სამიზნეს, LLDB ვერ იპოვის იმ პროექტის წყაროებს. Manifest-ის პროექტის საბაზო პარამეტრები ანიჭებენ უპირატესობას პროექტის დონის xcconfig მნიშვნელობებს, ამიტომ დააყენეთ ისინი უშუალოდ manifest-ში.

ამ პარამეტრების შეცვლა ცვლის კომპილაციის ქეშის გასაღებებს, ბინარული ქეშის ჰეშებს და შერჩევითი ტესტირების ჰეშებს, ამიტომ ეს ქეშები ხელახლა უნდა გათბეს. შეინარჩუნეთ არჩევანი თანმიმდევრული თქვენს გუნდში.

ქეშის ატვირთვის პოლიტიკა#

ნაგულისხმევად, ქეშის სერვისი იწერს და ტვირთავს არტეფაქტებს დაშორებულ ქეშში. თქვენ შეგიძლიათ აკონტროლოთ ეს xcodeCache პარამეტრით თქვენს Tuist.swift ფაილში, რათა ჩართოთ მხოლოდ-წაკითხვის რეჟიმი, სადაც არტეფაქტები იწერება, მაგრამ არასდროს იტვირთება:

swift

import ProjectDescription

let tuist = Tuist(
    fullHandle: "your-org/your-project",
    xcodeCache: .xcodeCache(
        upload: false
    ),
    project: .tuist(
        generationOptions: .options(
            enableCaching: true
        )
    )
)

ჩვეულებრივი პრაქტიკაა არტეფაქტების ატვირთვა მხოლოდ CI-დან, სადაც აგებები განმეორებადია, ხოლო ლოკალური გარემოები რჩება მხოლოდ-წაკითხვის რეჟიმში. ამის მიღწევა შეგიძლიათ Environment.isCI-ის გამოყენებით, რომელიც ამოწმებს CI გარემოს ცვლადს, რომელსაც აყენებს CI პროვაიდერების უმეტესობა:

swift

import ProjectDescription

let tuist = Tuist(
    fullHandle: "your-org/your-project",
    xcodeCache: .xcodeCache(
        upload: Environment.isCI
    ),
    project: .tuist(
        generationOptions: .options(
            enableCaching: true
        )
    )
)

ამ კონფიგურაციით, ლოკალური აგებები სარგებლობენ ქეშირებული არტეფაქტებით ატვირთვის გარეშე, ხოლო CI აგებები ავსებენ ქეშს დანარჩენი გუნდისთვის.

ატვირთვის პოლიტიკა იწერება პროექტის მიხედვით იმ მანქანაზე, რომელიც ასრულებს tuist setup cache-ს. მის შესაცვლელად, განაახლეთ upload და ხელახლა გაუშვით tuist setup cache, ასევე tuist generate, თუ Tuist გენერირებს თქვენს პროექტს. ამის შემდეგ ატვირთვები ემორჩილებიან ახალ პოლიტიკას იმ მანქანაზე ქეშის გადატვირთვის გარეშე. ერთი და იმავე პროექტის ჯობები, რომლებიც ერთდროულად მუშაობენ ერთ მანქანაზე, იზიარებენ მის პოლიტიკას, ამიტომ ყველა მათთვის გადაწყვეტილებას იღებს ყველაზე ახლანდელი tuist setup cache.

შენახვის ზომის ლიმიტი#

კომპილაციის ქეშის საცავი იზრდება ყოველი აგებისთან ერთად. პროექტის საცავების შესაზღუდად, დააყენეთ storeSizeLimit თქვენს Tuist.swift ფაილში:

swift

import ProjectDescription

let tuist = Tuist(
    fullHandle: "your-org/your-project",
    xcodeCache: .xcodeCache(
        storeSizeLimit: .gigabytes(20)
    ),
    project: .tuist(
        generationOptions: .options(
            enableCaching: true
        )
    )
)

როდესაც არცერთი აგება არ მიმდინარეობს, Tuist ამოწმებს პროექტის თითოეულ საცავს ყოველ 10 წუთში. ის შლის საცავის უძველეს ქეშირებულ შედეგებს, როდესაც ახალმა აგებებმა ჩაწერეს ლიმიტის დაახლოებით ნახევარი, რათა საცავი დასტაბილურდეს ლიმიტის დონეზე. საცავი შეიძლება იყოს ლიმიტზე მეტი, როდესაც აგებები მიმდინარეობს, და საცავი, რომელიც უკვე მეტი იყო ლიმიტის დაყენებისას, მცირდება, როდესაც ახალმა აგებებმა იმდენი ჩაწერეს. როდესაც რამდენიმე პროექტი იყენებს ერთსა და იმავე საცავს, როგორც ეს ხდება მისი ნაგულისხმევი ადგილმდებარეობით, მოქმედებს მათი ლიმიტებიდან უმცირესი. ლიმიტი მოქმედებს ყოველ მანქანაზე, სადაც თქვენ ასრულებთ tuist setup cache-ს, ამიტომ ხელახლა გაუშვით ის ლიმიტის შეცვლის შემდეგ.

მოდულის ქეშის ჰეშები#

კომპილაციის ქეშის პარამეტრები არ არის მოდულის ქეშის ჰეშების ნაწილი. Tuist ტოვებს ყოველ COMPILATION_CACHE_* აგების პარამეტრს და ყოველ -cas-plugin-option ფლაგს მისი მნიშვნელობით ჰეშის გარეთ. enableCaching-ის ჩართვა ან გამორთვა, ან ატვირთვის პოლიტიკის შეცვლა, ინარჩუნებს თქვენი სამიზნეების ჰეშებს, ამიტომ მოდულის ქეშის ბინარები, რომლებიც უკვე გაათბეთ, რჩებიან ვალიდურად. შეგიძლიათ შეადაროთ აგებები Xcode ქეშით და მის გარეშე ერთსა და იმავე მოდულის ქეშის მიმართ.

პრეფიქსის ასახვის პარამეტრები ჰეშირდება

Xcode 27-ზე და უფრო ახალ ვერსიებზე, enableCaching: true ასევე აყენებს SWIFT_ENABLE_PREFIX_MAPPING-ს, SWIFT_ENABLE_PROJECT_PREFIX_MAPPING-ს, CLANG_ENABLE_PREFIX_MAPPING-ს, CLANG_ENABLE_PROJECT_PREFIX_MAPPING-ს და TUIST_PREFIX_MAPPING_FOR_COVERAGE_* პარამეტრებს. ეს პარამეტრები არიან მოდულის ქეშის ჰეშების ნაწილი, ამიტომ Xcode 27-ზე და უფრო ახალ ვერსიებზე, enableCaching-ის ჩართვა ან გამორთვა ცვლის თქვენი სამიზნეების ჰეშებს.

დიდი შედეგების ნაწილების ხელახლა გამოყენება#

Xcode ქეშს შეუძლია შეამციროს გადაცემები შინაარსით განსაზღვრული დაყოფით. იმის ნაცვლად, რომ თითოეული დიდი შედეგი ჩაითვალოს წინა ვერსიებთან დაუკავშირებლად, ის ყოფს შეკუმშულ შედეგს მისი შინაარსით განსაზღვრულ საზღვრებზე. რედაქტირების შემდეგ, შესაბამისი ნაწილები შეიძლება ხელახლა იქნას გამოყენებული მაშინაც კი, როდესაც მათი ოფსეტები შეიცვალა.

ატვირთვები გზავნიან მხოლოდ იმ ნაწილებს, რომლებიც სერვერს აკლია. ჩამოტვირთვები ჯერ იღებენ ზუსტად ქეშირებულ ქმედებას და შედეგის ნაწილების რეცეპტს, შემდეგ კი ხელახლა იყენებენ ლოკალურ მანქანაზე შენახულ ვერიფიცირებულ ნაწილებს და იწერენ დაკარგულ ნაწილებს. სრულად აღდგენილი შედეგი ვერიფიცირდება სანამ ის აღდგება კომპილატორის ქეშში.

გადაცემის ნაწილების ქეში გამოყოფილია DerivedData-ისგან, ამიტომ მისი ნაწილები შეიძლება შენარჩუნდეს კომპილაციის ქეშის გაწმენდის ან ლოკალური ქეშის სერვისის გადატვირთვის შემდეგაც. ის არის დროებითი და შემოიფარგლება მაქსიმუმ ერთი gibibyte ნაწილის მონაცემებით, დამატებითი დროებითი staging ფაილით მაქსიმუმ ორი mebibyte ზომით. გამოძევებული ან დაზიანებული ნაწილები ხელახლა იწერება საჭიროების შემთხვევაში. კომპილაციის ქეშის შენარჩუნება თავისთავად კვლავ უფრო სწრაფია, ვიდრე მისი შინაარსის აღდგენა.

კლიენტი იყენებს ნაწილებად დაყოფილ გადაცემებს მხოლოდ მაშინ, როდესაც სერვერი აცხადებს თავსებად მხარდაჭერას. ძველ კლიენტებს შეუძლიათ კვლავ წაიკითხონ სრული შედეგები, ხოლო კლიენტები, რომლებიც დაკავშირებულია ძველ ან არამხარდაჭერილ სერვერებთან, ინარჩუნებენ ჩვეულებრივ გადაცემებს. მცირე ზომის შედეგები რჩებიან არსებულ მთლიანი-შედეგის გზაზე.

ეს ამცირებს გადაცემულ ბაიტებს, არა კომპილატორის გაუქმებას. საწყისი ფაილის შეცვლა კვლავ შეიძლება მოითხოვდეს კომპილაციას; ნაწილებად დაყოფა ეხმარება მიღებული შედეგის გამოქვეყნებას ან აღდგენას. დაზოგვა დამოკიდებულია შედეგსა და ცვლილებაზე, ხოლო „ცივ“ მანქანას, რომელსაც არ აქვს შესაბამისი ნაწილები, უნდა ჩამოტვირთოს შედეგი მთლიანად.

უწყვეტი ინტეგრაცია#

CI გარემოში ქეშირების ჩასართავად, თქვენ უნდა გაუშვათ იგივე ბრძანება, რაც ლოკალურ გარემოში: tuist setup cache.

ავთენტიკაციისთვის, შეგიძლიათ გამოიყენოთ ან OIDC ავთენტიკაცია (რეკომენდებულია მხარდაჭერილი CI პროვაიდერებისთვის) ან ანგარიშის ტოკენი TUIST_TOKEN გარემოს ცვლადის მეშვეობით.

GitHub Actions-ის სამუშაო ნაკადის მაგალითი OIDC ავთენტიკაციის გამოყენებით:

yaml

name: Build

permissions:
  id-token: write
  contents: read

jobs:
  build:
    runs-on: macos-latest
    steps:
      - uses: actions/checkout@v4
      - uses: jdx/mise-action@v2
      - run: tuist auth login
      - run: tuist setup cache
      - # Your build steps

იხილეთ უწყვეტი ინტეგრაციის სახელმძღვანელო მეტი მაგალითისთვის, მათ შორის ტოკენზე დაფუძნებული ავთენტიკაცია და სხვა CI პლატფორმები, როგორიცაა Xcode Cloud, CircleCI, Bitrise და Codemagic.

კომპილაციის ქეშის საცავი CI-ზე#

კომპილაციის ქეშის საცავი არის ლოკალური დირექტორია, სადაც Xcode ინახავს კომპილაციის შედეგებს. COMPILATION_CACHE_CAS_PATH აგების პარამეტრი განსაზღვრავს მის მდებარეობას, რომელიც ნაგულისხმევად არის CompilationCache.noindexDerivedData-ის შიგნით.

მდგომარეობის მქონე საცავი#

აგებებს შორის საცავის შესანარჩუნებლად, მიუთითეთ COMPILATION_CACHE_CAS_PATH (და TUIST_COMPILATION_CACHE_CAS_PATHtuist cache-სთვის) ერთ მყარ გზაზე და შეზღუდეთ მისი ზომა საცავის ზომის ლიმიტით.

პრობлемების გადაჭრა#

აგება აფრთხილებს, რომ Xcode ქეშის პროქსი ვერ მუშაობს#

თუ აგება აჩვენებს შემდეგნაირ გაფრთხილებას, რომელსაც Xcode უსვამს პრეფიქსად CAS error:-ს ან CAS operation failed:-ს, იმის მიხედვით, თუ რომელმა კომპილაციამ პირველად შეხვდა შეცდომას:

yaml

warning: CAS error: The Tuist Xcode cache proxy at /Users/you/.local/state/tuist/cas-proxy.sock failed (proxy connect: No such file or directory (os error 2)). Compilations that needed it used the local cache only, without remote cache hits. Their uploads are kept on disk and sent once the proxy is reachable again. Run `tuist setup cache` if the proxy is not running.

მაშინ კომპილაციის ქეშმა ვერ მიაღწია ლოკალურ ქეშის პროქსის, რომელსაც tuist setup cache აყენებს. აგება მაინც წარმატებით სრულდება, მაგრამ დაზარალებულ კომპილაციებს არ აქვთ remote cache hits, ამიტომ ის მუშაობს როგორც აგება ცარიელი ქეშით. მათი ატვირთვები ინახება დისკზე და იგზავნება მას შემდეგ, რაც პროქსი კვლავ დაამუშავებს მოთხოვნებს: იმავე აგების განმავლობაში, თუ ის დროულად დაბრუნდება, წინააღმდეგ შემთხვევაში იმავე მანქანაზე შემდეგი აგების დროს. CI მანქანა, რომელიც საქმის დასრულების შემდეგ იშლება, კარგავს მათ. გაფრთხილება ჩნდება ერთხელ ყოველ აგებაზე, Xcode-ის Issue navigator-ში და xcodebuild გამოტანაში.

იმის შესამოწმებლად, მუშაობს თუ არა პროქსი, ეძებეთ პროცესი, რომელიც უსმენს გაფრთხილებაში ნახსენებ სოკეტს:

bash

lsof ~/.local/state/tuist/cas-proxy.sock

თუ ბრძანება არაფერს ბეჭდავს, გაუშვით tuist setup cache პროქსის ხელახლა ასამუშავებლად. CI-ზე, გაუშვით tuist setup cache ნებისმიერ xcodebuild გამოძახებამდე ყოველ საქმეში.

აგებები უკიდურესად ნელია და გამოსცემს `CAS error: deadlineExceeded` გაფრთხილებებს#

თუ თქვენი აგებები მოსალოდნელზე ბევრად უფრო დიდხანს გრძელდება და Xcode აგების ჟურნალი სავსეა შემდეგნაირი გაფრთხილებებით:

bash

Warning: CAS error: deadlineExceeded(connectionError: Optional(connect(descriptor:addr:size:): No such file or directory (errno: 2)))
note: cache key query failed

ან:

bash

Warning: CAS error: deadlineExceeded(connectionError: Optional(connect(descriptor:addr:size:): Connection refused (errno: 61)))

მაშინ COMPILATION_CACHE_REMOTE_SERVICE_PATH მიუთითებს სოკეტზე, რომელსაც არავინ უსმენს, ჩვეულებრივ პროექტის მიხედვით სოკეტს (~/.local/state/tuist/<org>_<project>.sock), რომელსაც Tuist-ის ადრეული ვერსიები აყენებდნენ. Tuist აღარ ემსახურება ამ სოკეტს. Xcode ცდილობს კავშირის აღდგენას ყოველ კომპილაციის ქეშის მოთხოვნაზე სწრაფი შეცდომის ნაცვლად, რამაც შეიძლება აგება ერთ საათზე მეტხანს გაგრძელდეს, და Tuist-ს არ შეუძლია ამ ქცევის შეცვლა.

მის გამოსასწორებლად:

გენერირებული პროექტები: ხელახლა გაუშვით tuist generate.
სხვა პროექტები: ჩაანაცვლეთ COMPILATION_CACHE_* აგების პარამეტრები იმ პარამეტრებით, რომლებსაც tuist setup cache ბეჭდავს, როგორც ეს აღწერილია Xcode აგების პარამეტრების კონფიგურაცია-ში.

თუ არ იყენებთ Xcode ქეშს, წაშალეთ COMPILATION_CACHE_* აგების პარამეტრები და გაუშვით tuist teardown cache.

`uploaded CAS output` ჩნდება ლოკალურად მაშინაც კი, როდესაც ატვირთვები გამორთულია#

როდესაც დაყენებულია xcodeCache: .xcodeCache(upload: false) (ან upload: Environment.isCI არა-CI მანქანაზე), შეიძლება კვლავ ხედავდეთ note: uploaded CAS output ... აგების ჟურნალში. xcodebuild-ს არ აქვს გზა ამ გამოძახებების გამოტოვებისთვის, ამიტომ Tuist მაინც იღებს მათ, მაგრამ არაფერს აქვეყნებს Tuist სერვერზე. დაშბორდის მეტრიკა ითვალისწინებს ამას, ამიტომ არ არის მოხსენიებული ყალბი ატვირთვის ტრაფიკი.