მოდულის ქეში

მოთხოვნები

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

Tuist Module Cache უზრუნველყოფს აწყობის დროების ოპტიმიზაციის ძლიერ გზას თქვენი მოდულების ბინარებად (.xcframeworks) შენახვით და სხვადასხვა გარემოში მათი გაზიარებით. ეს შესაძლებლობა საშუალებას გაძლევთ გამოიყენოთ ადრე გენერირებული ბინარები, რაც ამცირებს განმეორებითი კომპილაციის საჭიროებას და აჩქარებს განვითარების პროცესს.

Xcode ქეშთან კომბინირება

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

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

გათბობა#

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

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

bash

tuist cache

ბრძანება ხელახლა იყენებს ბინარებს პროცესის დასაჩქარებლად.

თუ ბინარის ატვირთვა ვერ მოხერხდა, ბრძანება მაინც ატვირთავს დანარჩენს, შემდეგ კი გამოდის არანულოვანი სტატუსით და ჩამოთვლის მიზნებს, რომლებიც არ აიტვირთა. მანქანის ადგილობრივ ქეშში არსებული ბინარები ითვლება ქეშირებულად, ამიტომ იმავე მანქანიდან მათ ხელახლა ატვირთვისთვის, გათბობამდე გაუშვით tuist clean binaries. გადაეცით --no-upload ბინარების მხოლოდ ადგილობრივ ქეშში შესანახად.

დანიშნულების შერჩევა#

გამოიყენეთ --destination simulator ან --destination device ერთი დანიშნულებისთვის ქეშირებისა და გენერაციისთვის:

bash

tuist cache --destination simulator
tuist generate --destination simulator

tuist cache --destination device
tuist generate --destination device

ნაგულისხმევი მნიშვნელობაა all, რომელიც ინარჩუნებს თქვენი მიზნების მიერ მხარდაჭერილ ყველა დანიშნულებას, Mac Catalyst-ის ჩათვლით. მოგვიანებით tuist cache ხელახლა იყენებს ქეშირებულ ნაწილებს და აწყობს მხოლოდ დაკარგულ SDK-ებს. ჩვეულებრივი გენერაცია ინარჩუნებს მოდულის წყაროებს, თუ რომელიმე საჭირო ნაწილი აკლია.

შეზღუდული გენერაცია ზღუდავს წყაროს მიზნებს შერჩეული დანიშნულებით და ინარჩუნებს native macOS მიზნებს, მაკროსების ჩათვლით. არცერთი შეზღუდული რეჟიმი არ მოიცავს Mac Catalyst-ს. ხელახლა გააგენერირეთ --destination all-ით ყველა დანიშნულების აღსადგენად.

ნაწილ-ნაწილად ქეშირება მხარდაჭერილია iOS-ისა და macOS-ისთვის სტანდარტული არქიტექტურებით. სხვა პლატფორმები, მორგებული არქიტექტურები და არამხარდაჭერილი პროდუქტები ინარჩუნებენ სრული არტიფაქტის ქეშირებას. მემკვიდრეობითი მოდულის ქეშირება მოითხოვს --destination all-ს.

დაშორებული ატვირთვის დაშვება#

თანამედროვე მოდულის ქეშირება იყენებს REAPI-ს. როდესაც დატვირთული ქეში დროებით უარყოფს ატვირთვას RESOURCE_EXHAUSTED-ით, Tuist ამცირებს სიხშირეს jitter-ით, იცავს სტანდარტულ google.rpc.RetryInfo მინიმალურ დაყოვნებებს და ცდილობს ხელახლა შეზღუდული ლოდინის ბიუჯეტის ფარგლებში. ატვირთვის დაშვება საშუალებას აძლევს მაქსიმუმ ექვს ხელახლა ცდას თითოეული გამოძახებისთვის. თითოეული blob-ატვირთვის ოპერაცია იზიარებს ერთ 60-წამიან კუმულაციურ backoff ბიუჯეტს თავისი არსებობის შემოწმებებში, batch ატვირთვებში და streaming ჩაწერებში; პარალელური ლოდინები თითოეული მოიხმარს ბიუჯეტს, ამიტომ განმეორებითი უარები არ ანიჭებენ ყოველ რიგში მყოფ blob-ს კიდევ ერთ წუთს ხელახლა ცდებისთვის. წარმატებული გადაცემები არ მოიხმარენ ამ ბიუჯეტს და არ ჩერდებიან, როდესაც ის ამოიწურება. Action-result-ის გამოქვეყნებას აქვს საკუთარი შეზღუდული ბიუჯეტი. ექსპონენციალური დაყოვნება იწყება ერთი წამით და იზრდება 30 წამისკენ პროპორციული jitter-ის წინ. თუ სერვერის მოთხოვნილი დაყოვნება აღემატება დარჩენილ ბიუჯეტს, Tuist ვერ ახერხებს, ვიდრე ხელახლა სცადოს მითითებულზე ადრე. გაუქმება წყვეტს backoff-ს, ხოლო ქეშის წაკითხვები ინარჩუნებენ მოკლე ხელახლა ცდებს, რათა გადატვირთვამ არ შეაფერხოს გენერაცია.

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

კონფიგურაციის შერჩევა#

როდესაც ათბობთ ქეშს --configuration-ის გადაცემის გარეშე, Tuist ირჩევს გამოყენებისთვის აწყობის კონფიგურაციას შემდეგი თანმიმდევრობით:

defaultConfiguration დაყენებული თქვენს manifest-ის Project.Options.generationOptions-ში, თუ არსებობს.
წინააღმდეგ შემთხვევაში, პირველი აწყობის კონფიგურაცია ვარიანტის debug სახელით ანბანური თანმიმდევრობით.

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

bash

tuist cache --configuration Release

გამოყენება#

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

bash

tuist generate # Only dependencies
tuist generate Search # Dependencies + Search dependencies
tuist generate Search Settings # Dependencies, and Search and Settings dependencies
tuist generate --cache-profile none # No cache at all

bash

tuist test

Warning

ბინარული ქეშირება არის ფუნქცია, შექმნილი განვითარების სამუშაო პროცესებისთვის, როგორიცაა აპლიკაციის გაშვება სიმულატორზე ან მოწყობილობაზე, ან ტესტების გაშვება. ის არ არის განკუთვნილი release აწყობებისთვის. აპლიკაციის დაარქივებისას, გააგენერირეთ პროექტი წყაროებით --cache-profile none-ის გამოყენებით.

ქეშის პროფილები#

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

ჩაშენებული:
- only-external: ჩაანაცვლე მხოლოდ გარე დამოკიდებულებები (სისტემის ნაგულისხმევი)
- all-possible: ჩაანაცვლე რაც შეიძლება მეტი მიზანი (შიდა მიზნების ჩათვლით)
- none: არასდროს ჩაანაცვლო ქეშირებული ბინარებით

აირჩიეთ პროფილი --cache-profile-ით tuist generate-ზე:

bash

# Built-in profiles
tuist generate --cache-profile all-possible

# Custom profiles (defined in Tuist Config)
tuist generate --cache-profile development

# Use config default (no flag)
tuist generate

# Focus on specific targets (implies all-possible)
tuist generate MyModule AnotherTarget

# Disable binary replacement entirely
tuist generate --cache-profile none

მოძველებული ფლაგი

--no-binary-cache ფლაგი მოძველებულია. გამოიყენეთ --cache-profile none მის ნაცვლად. მოძველებული ფლაგი კვლავ მუშაობს უკუთავსებადობისთვის.

პრიორიტეტი ეფექტური ქცევის განსაზღვრისას (უმაღლესიდან უმდაბლესამდე):

--cache-profile none
მიზნის ფოკუსი (generate-ისთვის მიზნების გადაცემა) → პროფილი all-possible
--cache-profile <value>
კონფიგურაციის ნაგულისხმევი (თუ დაყენებულია)
სისტემის ნაგულისხმევი (only-external)

მხარდაჭერილი პროდუქტები#

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

ჩარჩოები (სტატიკური და დინამიკური), ტესტირების მხარდაჭერის ჩარჩოების ჩათვლით, რომლებიც დამოკიდებულნი არიან XCTest-ზე ან Swift Testing-ზე
ბიბლიოთეკები (სტატიკური და დინამიკური), ტესტირების მხარდაჭერის ბიბლიოთეკების ჩათვლით, რომლებიც დამოკიდებულნი არიან XCTest-ზე ან Swift Testing-ზე
ბანდლები
Swift Macros

ტესტის ბანდლები გამორიცხული რჩება მოდულის ქეშიდან. ეს ნიშნავს, რომ unitTests და uiTests მიზნები არ ინახება ბინარების სახით, მაგრამ რეგულარული ჩარჩოსა და ბიბლიოთეკის მიზნები, რომლებზეც ტესტებია დამოკიდებული, შეიძლება შეინახონ ქეშში მაშინაც კი, თუ ისინი აკავშირებენ XCTest-ს ან Swift Testing-ს.

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

ზემოთ დამოკიდებულებები

როდესაც მიზანი არ არის ქეშირებადი, ის ასევე არაქეშირებადს ხდის ზემოთ დამოკიდებულ მიზნებს. მაგალითად, თუ გაქვთ დამოკიდებულების გრაფი A > B, სადაც A დამოკიდებულია B-ზე, თუ B არ არის ქეშირებადი, A ასევე არ იქნება ქეშირებადი.

ანალიტიკა#

გახსენით Module Cache → Modules თქვენი პროექტის დაფაზე, რათა იპოვოთ მოდულები ხშირი გამოტოვებით. აირჩიეთ გარემო, რომლის გაუმჯობესებაც გსურთ, მაგალითად CI, და თარიღთა დიაპაზონი. მიმოხილვა აჩვენებს ქეშის მოხვედრებს, გამოტოვებებს და მოდულებს გამოტოვებებით; მოდულის გახსნა აჩვენებს მის ისტორიას და თითოეული დაკვირვებისთვის მინიჭებულ მიზეზს.

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

გამოტოვების მიზეზები#

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

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

მაგალითად:

სცენარი	კლასიფიკაცია
მოდული აკლია ადრეული დაკვირვების ან კვალიფიციური დისტანციური მოხვედრის გარეშე	ცივი
A იცვლება; B დამოკიდებულია A-ზე, და C დამოკიდებულია B-ზე; სამივე გასაღები იცვლება	A არის Changed; B და C არიან Upstream
კომპილატორის ვერსია იცვლება გათბობის შემდეგ, წყაროები და პარამეტრები უცვლელია	დაზარალებული გამოტოვებები არიან Changed, როდესაც ორივე დაკვირვება იუწყება კომპილატორის შეყვანებს
ზუსტი გასაღები ჩამოტვირთული იყო დისტანციურად, შემდეგ აკლია მისი არტიფაქტის გამოძევების შემდეგ	Evicted, როდესაც ადრეული მოხვედრა კვალიფიცირდება როგორც მტკიცებულება
გასაღები განმეორებით აკლია და არასდროს ყოფილა წარმატებით გათბილი	შეიძლება დარჩეს Cold

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

ქეშის მოხვედრის სიხშირის გაუმჯობესება#

აირჩიეთ თანმიმდევრული საწყისი წერტილი. დაიწყეთ CI-ით და რეპრეზენტატიული თარიღების დიაპაზონით. დაალაგეთ მოდულები გამოტოვებების მიხედვით, შემდეგ გაითვალისწინეთ მათი მოხვედრის სიხშირე, დამოკიდებულებები და აგების ღირებულება. ხშირად გამოტოვებული, ძვირი დამოკიდებულების გამოსწორებამ შეიძლება უფრო მეტი დრო დაგიზოგოთ, ვიდრე პატარა მოდულის მოხვედრის სიხშირის გაუმჯობესებამ. ცვლილების შეტანის შემდეგ შეადარეთ ერთი და იგივე გარემო და მსგავსი დატვირთვები.
შეისწავლეთ Changed გამოტოვებები. გახსენით შესაბამისი გაშვებები და შეადარეთ მათი სრული გასაღებები და მოხსენებული შეყვანები. დააწყეთ გათბობისა და მომხმარებელი სამუშაოები სასურველ Xcode/კომპილატორის ვერსიაზე, კონფიგურაციაზე და სამიზნე დანიშნულებებზე. განახორციელეთ ხელახლა გათბობა განზრახული ცვლილებების შემდეგ. თუ არამდგრადი გენერირებული ფაილები ან გარემოზე დამოკიდებული პარამეტრები აუქმებს წინათ სტაბილურ მოდულებს, შეისწავლეთ ეს შეყვანები. შეინახეთ ბინარულ თავსებადობაზე მოქმედი შეყვანები ჰეშში.
მიჰყევით Upstream გამოტოვებებს შეცვლილ დამოკიდებულებამდე. შეამოწმეთ მისი ისტორია პირდაპირი ცვლილების საპოვნელად. მიღებული გასაღებების გათბობამ შეიძლება აღადგინოს ხელახლა გამოყენება. თუ ხშირად ცვალებადი იმპლემენტაცია აუქმებს ბევრ ძვირ დამოკიდებულებას, განიხილეთ უფრო პატარა მოდულები ან სტაბილური ინტერფეისები, როგორც აღწერილია Efficiency-ში.
შეამოწმეთ გათბობის დაფარვა Cold გამოტოვებებისთვის. დარწმუნდით, რომ გათბობა ირჩევს საჭირო მოდულებს, იყენებს მომხმარებელი სამუშაოს კონფიგურაციასა და გარემოს და წარმატებით ტვირთავს არტიფაქტებს. შეამოწმეთ სრული გასაღებები, რომლებსაც იყენებენ რეალური CI სამუშაოები. თუ გათბობა და მოხმარება სხვადასხვა გასაღებებს ითხოვენ, შეამოწმეთ ჰეშის შეყვანები, სანამ ვარაუდს გამოთქვამთ, რომ ქეში გამოევად. განმეორებითი გამოტოვებები ადრეული წარმატებული ატვირთვის გარეშე შესაძლებელია მაშინაც კი, თუ მოდულის წყაროები არ შეცვლილა.
გამოიყენეთ მტკიცებულება Evicted გამოტოვებებისთვის. დაადასტურეთ მომხმარებელი გაშვების გასაღები და ბოლოწერტილი, შემდეგ შეამოწმეთ მომხმარებელი გაშვების ქეშის გაფრთხილებები და გათბობის სამუშაოს ატვირთვის შედეგი. შეამოწმეთ შენახვა ან გამოძევება, სადაც ეს შესაბამისია. ხელახლა გაათბეთ საჭირო არტიფაქტები და დაადასტურეთ მომდევნო მოხვედრა. თუ ისინი კვლავ აკლიან, გაუზიარეთ შესაბამისი გაშვების ბმულები და ლოგები მხარდაჭერას.

ჰეშის შესადარებლად, გაუშვით ეს თითოეულ შესაბამის გარემოში, იმ კონფიგურაციის გამოყენებით, რომლის გათბობა და მოხმარებაც გსურთ:

bash

tuist hash cache --configuration Debug --verbose

შეადარეთ მოდულის სრული ჰეში და კომპონენტის ბლოკი. იმავე უცვლელ მანქანაზე ბრძანების გამეორებამ ჩვეულებრივ იგივე შედეგი უნდა მოიტანოს; შეადარეთ რეალური გათბობისა და მოხმარების გარემოები შეუსაბამობის შესასწავლად. არცერთ ბრძანებას არ სჭირდება ქეშში მოხვედრა. იხილეთ ჰეშის დიაგნოსტიკა დამატებითი შემოწმებებისთვის.

ეფექტურობა#

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

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

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

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

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

შეინახეთ ქეშის გათბობა იზოლირებულად

გაუშვით tuist cache ცალკეულ CI ნაბიჯში, გენერირებულ სამუშაო სივრცეზე დამოკიდებული მომდევნო ნაბიჯების გარეშე. ვინაიდან tuist cache ცვლის სამუშაო სივრცეს ქეშის აგების მიზნებისთვის, ნებისმიერმა CI ნაბიჯმა, რომელსაც სჭირდება სამუშაო სივრცე, ჯერ უნდა გაუშვას tuist generate, რათა მიიღოს ახალი, გამოსაყენებელი სამუშაო სივრცე.

ქეშის გათბობა იყენებს ბინარებს

tuist cache ბრძანება ასევე იყენებს ბინარულ ქეშს გათბობის დასაჩქარებლად.

ქვემოთ მოცემულია რამდენიმე მაგალითი ჩვეულებრივი სამუშაო ნაკადებისა:

დეველოპერი იწყებს მუშაობას ახალ ფუნქციაზე#

ის ქმნის ახალ შტოს main-დან.
ის უშვებს tuist generate-ს.
Tuist იღებს ყველაზე ახალ ბინარებს main-დან და გენერირებს პროექტს მათთან ერთად.

დეველოპერი აგზავნის ცვლილებებს upstream-ში#

CI პაიპლაინი გაუშვებს xcodebuild build-ს ან tuist test-ს პროექტის აგების ან ტესტირებისთვის.
სამუშაო ნაკადი გამოიტანს ყველაზე ახალ ბინარებს main-დან და გენერირებს პროექტს მათთან ერთად.
შემდეგ ის ინკრემენტულად ააგებს ან შეამოწმებს პროექტს.

კონფიგურაცია#

ქეშის კონკურენტულობის ლიმიტი#

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

bash

TUIST_CACHE_CONCURRENCY_LIMIT=2 tuist cache

როდესაც დაყენებული არ არის, REAPI ატვირთვები იყენებენ რვა გადაცემის ამოცანას. ჩამოტვირთვები იყენებენ რვას, როდესაც ნებისმიერი blob საჭიროებს ByteStream-ს და 32-ს მხოლოდ batch გეგმებისთვის. ძველი HTTP ქეშის გზის ნაგულისხმები მნიშვნელობა არის 100; ეს ნაგულისხმები მნიშვნელობა არ ვრცელდება REAPI-ზე. არასწორი მნიშვნელობები, მათ შორის ადრე დოკუმენტირებული none, ინარჩუნებენ ნაგულისხმევ მნიშვნელობებს ლიმიტების მოხსნის ნაცვლად. გამოიყენეთ unset TUIST_CACHE_CONCURRENCY_LIMIT ნაგულისხმევი მნიშვნელობების აღდგენისთვის.

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

ქეშის გათბობის დროებითი დირექტორია#

ნაგულისხმევად, tuist cache ქმნის დროებით დირექტორიას აგების შუალედური ფაილებისა და აწყობილი ქეშის არტიფაქტებისთვის, შემდეგ კი შლის მას ქეშის გათბობის დასრულებისას. იმისთვის, რომ ეს ფაილები შეინახოთ თქვენს მიერ მართულ დირექტორიაში, დააყენეთ TUIST_CACHE_WARM_SCRATCH_DIRECTORY.

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

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

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

კოდის დაფარვა#

EARLY ACCESS

კოდის დაფარვა მოდულის ქეშთან ერთად არის ადრეული წვდომის რეჟიმში. ბრძანებები კითხულობენ და ათბობენ ქვემოთ აღწერილ ინსტრუმენტულ ბინარებს მხოლოდ მაშინ, როდესაც TUIST_FEATURE_FLAG_COVERAGE=1 არის დაყენებული.

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

swift

import ProjectDescription

let tuist = Tuist(
    project: .tuist(
        generationOptions: .options(
            coverage: .coverage(enabled: true)
        )
    )
)

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

ბრძანება	თქვენი პროექტის სამიზნეები	გარე პაკეტები
`tuist cache` (Debug კონფიგურაცია)	ათბობს ინსტრუმენტულ ბინარებს	ათბობს ჩვეულებრივ ბინარებს
`tuist cache` (Release კონფიგურაცია)	ათბობს ჩვეულებრივ ბინარებს	ათბობს ჩვეულებრივ ბინარებს
`tuist hash cache`	ბეჭდავს ინსტრუმენტულ გასაღებებს	ბეჭდავს ჩვეულებრივ გასაღებებს
`tuist generate`	კითხულობს ინსტრუმენტულ ბინარებს	კითხულობს ჩვეულებრივ ბინარებს
`tuist test`	კითხულობს ინსტრუმენტულ ბინარებს	კითხულობს ჩვეულებრივ ბინარებს

ოფცია ვრცელდება ყოველ კონფიგურაციაზე, რომელსაც Xcode განიხილავს როგორც Debug-ს. Release აგებები არასდროს არის ინსტრუმენტირებული. Tuist ასევე აკავშირებს პროფილის runtime-ს ამ კონფიგურაციებში (CLANG_COVERAGE_MAPPING_LINKER_ARGS), ასე რომ აგებები, რომლებიც არ აგროვებენ დაფარვას, მაინც აკავშირებენ ინსტრუმენტულ ბინარებს და რთავენ დაფარვას ავტომატურად გენერირებული სქემების ტესტის მოქმედებაში და თქვენს მიერ განსაზღვრულ სქემებში, რომლებშიც coverage არ არის დაყენებული.

თქვენს მიერ განსაზღვრული სქემა მიჰყვება ოფციას, თუ ის თავად არ აყენებს დაფარვას: .options(coverage: false) ტოვებს მას გამორთულს და .options(coverage: true) ტოვებს მას ჩართულს, რაც არ უნდა ეწეროს ოფციაში. ტესტის გეგმები თავად გადაწყვეტენ დაფარვას და -enableCodeCoverage მაინც გადაფარავს გაშვებას, როგორც Xcode-ში. გაშვება, რომელიც კითხულობს ინსტრუმენტულ ბინარებს დაფარვის შეგროვების გარეშე, აგებს და ტესტავს ჩვეულებრივად. როდესაც გაშვება აგროვებს დაფარვას, მაგრამ თქვენი პროექტის სამიზნეები ქეშიდან მოვიდნენ როგორც ჩვეულებრივი ბინარები, Tuist აფრთხილებს, რომ მათი დაფარვა არ იზომება.

TUIST_COVERAGE_ENABLED გარემოს ცვლადი (1 ან 0) აქვს უპირატესობა coverage: .coverage(enabled:)-ზე. დააყენეთ ის მთელი გარემოსთვის, მაგალითად CI ნაკადისთვის, და არა ერთი ბრძანებისთვის, იმისთვის, რომ ბრძანებები, რომლებიც ათბობენ ქეშს და ისინი, რომლებიც კითხულობენ მას, შეთანხმდნენ.

prefixMapping (იხილეთ Xcode cache) აქვს საკუთარი გადაფარვა: TUIST_COVERAGE_PREFIX_MAPPING გარემოს ცვლადი (1 ან 0) აქვს უპირატესობა coverage: .coverage(prefixMapping:)-ზე.

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

KEEP THE VALUES THE SAME EVERYWHERE

enabled და prefixMapping ცვლიან თქვენი პროექტის სამიზნეების აგების პარამეტრებს და ქეშის გასაღებებს, ასევე მისი ტესტის სამიზნეების შერჩევითი ტესტირების ჰეშებს. დააყენეთ ისინი იმავე მნიშვნელობაზე ყოველ მანქანაზე, რომელიც იზიარებს ქეშს და არ მიიღოთ ისინი გარემოდან (მაგალითად Environment.isCI-დან): მნიშვნელობა, რომელიც განსხვავდება CI-სა და ლოკალურ მანქანებს შორის, აძლევს მათ განსხვავებულ გასაღებებს. იგივე ეხება გარემოს ცვლადებს: გაშვება TUIST_COVERAGE_ENABLED=0-ით არ იყენებს ხელახლა ბინარებს ან შერჩევითი ტესტირების შედეგებს ჩართული დაფარვის გაშვებებიდან.

გაითვალისწინეთ:

ინსტრუმენტული ბინარები უფრო დიდია: დაახლოებით 20–30%-ით სტატიკური არქივებისა და დინამიური ბიბლიოთეკებისთვის. Debug აგებები მუშაობენ იმავე სიჩქარით.
Xcode-ის დაფარვის ანგარიში არასდროს აჩვენებს კოდს, რომელიც მოვიდა ქეშიდან, ამ ოფციის ჩართვით ან გამორთვით. Tuist-ის დაფარვის ატვირთვა ზომავს მას. იმისთვის, რომ ნახოთ სამიზნის დაფარვა Xcode-ში, ფოკუსირდით მასზე tuist generate <target>-ით, რათა ის აიგოს წყაროდან.

პრობლემების მოგვარება#

ის არ იყენებს ბინარებს ჩემი სამიზნეებისთვის#

დარწმუნდით, რომ ჰეშები არის დეტერმინისტული გარემოებსა და გაშვებებს შორის. ეს შეიძლება მოხდეს, თუ პროექტს აქვს მითითებები გარემოზე, მაგალითად აბსოლუტური გზების მეშვეობით. შეგიძლიათ გამოიყენოთ diff ბრძანება ორი თანმიმდევრული tuist generate გამოძახებით გენერირებული პროექტების შესადარებლად ან გარემოებსა და გაშვებებს შორის.

ასევე დარწმუნდით, რომ სამიზნე არ არის დამოკიდებული პირდაპირ ან ირიბად არაქეშირებად სამიზნეზე.

დაკარგული სიმბოლოები#

წყაროების გამოყენებისას, Xcode-ის აგების სისტემას, Derived Data-ს მეშვეობით, შეუძლია გადაწყვიტოს დამოკიდებულებები, რომლებიც არ არის ცხადად განცხადებული. თუმცა, როდესაც ეყრდნობით ბინარულ ქეშს, დამოკიდებულებები უნდა იყოს ცხადად განცხადებული; წინააღმდეგ შემთხვევაში, სავარაუდოდ, ნახავთ კომპილაციის შეცდომებს, როდესაც სიმბოლოებს ვერ პოულობთ. ამის დებაგინგისთვის, გირჩევთ გამოიყენოთ tuist inspect dependencies --only implicit ბრძანება და დააყენოთ ის CI-ში, რათა თავიდან აიცილოთ რეგრესიები იმპლიციტურ დაკავშირებაში.