გამართვა

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

Warning

სესიის მონაცემები შეიძლება შეიცავდეს მგრძნობიარე ინფორმაციას, როგორიცაა ფაილის გზები, პროექტის სახელები და მოთხოვნის/პასუხის სხეულები. მიუხედავად იმისა, რომ მგრძნობიარე ჰედერები (მაგალითად, Authorization) ინიღბება, იყავით ყურადღებიანი სესიის მონაცემების სხვებთან გაზიარებისას.

სესიის მონაცემები#

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

ყოველ გაშვებაზე ის ქმნის სესიის დირექტორიას $XDG_STATE_HOME/tuist/sessions/{uuid}/-ში, სადაც $XDG_STATE_HOME იღებს მნიშვნელობას ~/.local/state, თუ გარემოს ცვლადი არ არის დაყენებული. ასევე შეგიძლიათ გამოიყენოთ $TUIST_XDG_STATE_HOME Tuist-ისთვის სპეციფიკური მდგომარეობის დირექტორიის დასაყენებლად, რომელსაც აქვს უპირატესობა $XDG_STATE_HOME-თან შედარებით.

ყოველი სესიის დირექტორია შეიცავს:

logs.txt - ტექსტური ლოგები CLI სესიიდან
network.har - HTTP Archive (HAR) ფაილი, რომელიც შეიცავს სესიის განმავლობაში შესრულებულ ყველა ქსელურ მოთხოვნას და პასუხს

HAR ფაილების ვიზუალიზაცია#

HAR ფაილი აღრიცხავს სესიის განმავლობაში შესრულებულ ყველა HTTP მოთხოვნას და პასუხს, რაც სასარგებლოა სერვერთან კომუნიკაციის პრობლემების გამოსასწორებლად. HAR ფაილების გახსნა შეგიძლიათ რამდენიმე ინსტრუმენტით:

Proxyman: macOS-ის ნატიური აპლიკაცია HTTP ტრაფიკის სანახავად და ანალიზისთვის. HAR ფაილის იმპორტი ხდება File > Import-ის მეშვეობით.
ბრაუზერის დეველოპერული ინსტრუმენტები: Chrome, Firefox და Safari მხარდაჭერენ HAR ფაილების იმპორტს თავიანთ Network ჩანართში.
HAR Viewer: ვებზე დაფუძნებული HAR ფაილების ნახვის ინსტრუმენტი.

Tip

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

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

5 დღეზე ძველი სესიის დირექტორიები ავტომატურად იშლება. Tuist ნაგულისხმევად ინახავს მაქსიმუმ 50 არააქტიურ სესიის დირექტორიას, თუმცა ინარჩუნებს იმ სესიებს, რომლებიც ეკუთვნის ამჟამად გაშვებულ Tuist პროცესებს. CI გარემოებში, სადაც ერთი და იგივე მდგომარეობის დირექტორიით ბევრი Tuist ბრძანება სრულდება, შეგიძლიათ გაზარდოთ არააქტიური სესიების ზღვარი TUIST_SESSION_MAX_SESSIONS-ით, მაგალითად TUIST_SESSION_MAX_SESSIONS=200. არასწორი მნიშვნელობები, ნული და უარყოფითი მნიშვნელობები იგნორირდება და Tuist ბრუნდება ნაგულისხმევ 50-ზე.

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

CI-ში, სადაც გარემოებები დროებითია, შეიძლება გსურთ დააკონფიგურიროთ თქვენი CI პაიპლაინი Tuist სესიის მონაცემების ექსპორტისთვის. არტიფაქტების ექსპორტი CI სერვისებში ჩვეულებრივი შესაძლებლობაა და კონფიგურაცია დამოკიდებულია თქვენს მიერ გამოყენებულ სერვისზე. მაგალითად, GitHub Actions-ში შეგიძლიათ გამოიყენოთ actions/upload-artifact action სესიის მონაცემების არტიფაქტად ასატვირთად:

yaml

name: Node CI

on: [push]

env:
  TUIST_XDG_STATE_HOME: /tmp

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
      # ... other steps
      - run: tuist generate
      # ... do something with the project
      - name: Export Tuist session data
        if: failure()
        uses: actions/upload-artifact@v4
        with:
          name: tuist-sessions
          path: /tmp/tuist/sessions/

Xcode ქეშის გამართვა#

Xcode ქეშის პრობლემების გამოსასწორებლად, დააყენეთ TUIST_CAS_LOG ფაილის გზაზე როგორც tuist setup cache-ის გაშვებისას, ისე ბილდის დროს. Tuist ამ ფაილს ამატებს ქეშის სტატისტიკას და შეცდომებს:

bash

export TUIST_CAS_LOG=$HOME/.local/state/tuist/cas.log
tuist setup cache
xcodebuild build -scheme YourScheme

CI-ზე Tuist წერს ამ ლოგს ~/.local/state/tuist/cas.log-ში ნებისმიერი კონფიგურაციის გარეშე.

ქსელური ტაიმაუთებისა და ხელახალი ცდების რეგულირება#

Tuist-ის მთელი Hypertext Transfer Protocol (HTTP) ტრაფიკი, მათ შორის სერვერის გამოძახებები, რეესტრი, პრევიუები და ქეშის არტიფაქტების გადაცემა, გადის საერთო URLSession-ზე გონივრული ნაგულისხმევი პარამეტრებით. ნელი ან გადატვირთული ქსელური გზებზე (მაგალითად, თვითმასპინძელი განლაგება, რომელიც ობიექტურ საცავს აღწევს კორპორატიული პროქსის მეშვეობით), ცალკეულ მოთხოვნას შეიძლება არ ეყოს რესურსი და მიაღწიოს რესურსის ტაიმაუთს სანამ დასრულდება. კერძოდ, ქეშის ჩამოტვირთვისას, ტაიმაუთის მიღწევა აიძულებს Tuist-ს დაუბრუნდეს მოდულის წყაროდან აგებას, რაც გაცილებით ძვირია, ვიდრე ქეშში არსებული ბინარისთვის ოდნავ მეტხანს ლოდინი. შეგიძლიათ შეცვალოთ ძირითადი პარამეტრები გარემოს ცვლადების მეშვეობით, სადაც ნაგულისხმევი მნიშვნელობები გამოიყენება, თუ ისინი არ არის დაყენებული ან დაყენებულია არასწორ მნიშვნელობაზე:

bash

# Maximum time (in seconds) a single resource transfer can take before it's cancelled
# (default: 90, or 600 for whole-file transfers such as test-product shard artifacts)
export TUIST_HTTP_TIMEOUT_INTERVAL_FOR_RESOURCE=600

# Maximum time (in seconds) to wait for new data on an existing request (default: 120)
export TUIST_HTTP_TIMEOUT_INTERVAL_FOR_REQUEST=300

# Maximum number of simultaneous connections per host (default: 20)
export TUIST_HTTP_MAXIMUM_CONNECTIONS_PER_HOST=40

# Maximum retries after the initial attempt (default: 3, maximum: 10)
export TUIST_HTTP_MAXIMUM_RETRY_COUNT=1

# Initial exponential backoff delay in milliseconds (default: 100, maximum: 30000)
export TUIST_HTTP_RETRY_BASE_DELAY_IN_MILLISECONDS=250

რესურსის მოლოდინის დრო არის მთლიანი გადაცემის საათისმიერი ზედა ზღვარი და არა გაჩერების კონტროლი, ამიტომ ის უნდა იყოს საკმარისად დიდი თქვენს მიერ გადაადგილებული უდიდესი არტიფაქტისთვის. მთლიანი ფაილის გადაცემები, როგორიცაა შარდის მიერ ჩამოტვირთული ტესტის პროდუქტები, ნაგულისხმევად 10 წუთია და არა 90 წამი, ხოლო გაჩერებული გადაცემა მაინც შეწყდება TUIST_HTTP_TIMEOUT_INTERVAL_FOR_REQUEST ახალი მონაცემების გარეშე. ეს გადაცემები კითხულობენ TUIST_HTTP_TIMEOUT_INTERVAL_FOR_RESOURCE მხოლოდ თავიანთი ზედა ზღვრის გაზრდისთვის და არასდროს ამცირებენ მას 10 წუთზე ნაკლებად, ამიტომ ქეშის მოთხოვნების სწრაფად შეცდომისთვის შერჩეული მნიშვნელობა არ ასრულებს შარდის მიერ ტესტის პროდუქტების ჩამოტვირთვას. TUIST_HTTP_TIMEOUT_INTERVAL_FOR_RESOURCE-ის გაზრდა საშუალებას აძლევს აღდგენად, მაგრამ ნელ ჩამოტვირთვას დასრულდეს ვადის ამოწურვის ნაცვლად. ქეშის ჩამოტვირთვებისთვის ეს ნიშნავს ქეშში მოხვედრას წყაროდან ბილდზე გადასვლის ნაცვლად, ამიტომ გაზარდეთ იგი განზრახ: ერთი და იგივე მნიშვნელობა, რომელიც ინარჩუნებს ნელ ქეშის ჩამოტვირთვას, ასევე აყოვნებს წყაროდან ბილდზე გადასვლას. TUIST_HTTP_MAXIMUM_RETRY_COUNT-ის შემცირებას შეუძლია ხელი შეუშალოს უფრო ხანგრძლივ მოლოდინის დროს რამდენიმე ცდის განმავლობაში უარესი შემთხვევის ლოდინის გამრავლებაში. ხელახლა ცდის დაყოვნებები ორმაგდება ყოველი შეცდომის შემდეგ, მოიცავს შემთხვევითი ჯიტერის ერთ ბაზისურ დაყოვნებას და არასდროს აღემატება 30 წამს.

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

ნაგულისხმევად, Tuist ამოწმებს TLS სერტიფიკატებს ოპერაციული სისტემის root store-ის მიმართ. როდესაც აწარმოებთ თვითმასპინძელ Tuist ან Kura სერვერს, რომელიც იყენებს პირად სერტიფიკატების გამცემს (CA), Tuist-საც უნდა ენდოს ეს CA. root-ის System keychain-ში დაყენება (და SSL-ისთვის სანდოდ მონიშვნა) არის სტანდარტული მიდგომა, მაგრამ ეს ხშირად პრაქტიკული არ არის headless CI ჰოსტებზე, სადაც არ არის GUI სესია ან მობილური მოწყობილობების მართვა (MDM) სანდოობის ბიტის დასაყენებლად.

ამ შემთხვევებში შეგიძლიათ პირდაპირ მიუთითოთ Tuist-ს CA სერტიფიკატების კონაზე. კონა შეიძლება იყოს PEM (ერთი ან რამდენიმე შეერთებული -----BEGIN CERTIFICATE----- ბლოკი) ან ერთი DER ფაილი. სისტემის root store რჩება სანდოდ მის გვერდით, ამიტომ საჯარო სერტიფიკატები ჩვეულებრივად მოწმდება და სერტიფიკატების შეფასება არასდროს გამოიტოვება.

bash

# Path to a PEM/DER CA bundle to trust on top of the system root store (default: unset)
export TUIST_CA_CERTIFICATE=/etc/ssl/certs/self-hosted-ca.pem

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

toml

[network]
ca_certificate = "/etc/ssl/certs/self-hosted-ca.pem"

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