# Elixir-ის კეშის გაფართოებული კონფიგურაცია

დაიწყეთ <.localized_link href="/guides/features/cache/elixir">Elixir-ის კეშის დაყენების სახელმძღვანელოთი</.localized_link>. ქვემოთ მოცემული პარამეტრები საჭიროა მხოლოდ მაშინ, როდესაც თქვენს პროექტს აქვს დამატებითი კომპილაციის შემავალი მონაცემები, დამოკიდებულების გამონაკლისები ან სხვადასხვა checkout-ის გზები.

## დამოკიდებულებების შერჩევა

`cache: true` ავტომატურად ინახავს მხარდაჭერილ დამოკიდებულებებს. საკვანძო სიაში იგივე ავტომატური შერჩევა მოქმედებს, არჩევითი გადაწერებით:

```elixir
cache: [exclude: [:a_dependency_with_compile_time_side_effects]]
```

კეშირების მხოლოდ კონკრეტულ დამოკიდებულებებზე შემოსაზღვრად:

```elixir
cache: [dependencies: [:nimble_options, :nimble_parsec]]
```

`dependencies: :all` ცალსახად ირჩევს ყველა მხარდაჭერილ დამოკიდებულებას; `dependencies: []` არ ირჩევს არცერთს. `exclude:` უპირატესობა აქვს ნებისმიერ შერჩევასთან მიმართებაში. `cache`-ის გამოტოვება, ან მისი `false` ან `nil`-ზე დაყენება, თიშავს კეშირებას.

მხარდაჭერილი დამოკიდებულებები იტვირთება Hex-ის ან Git-ის მეშვეობით და იყენებენ Mix-ის სტანდარტულ კომპილატორის პაიპლაინს Elixir/Erlang წყაროებით, ან rebar3-ის ჩვეულებრივ სუფთა-BEAM კომპილაციას. Mix-ის დამოკიდებულებებს ასევე შეუძლიათ არტიფაქტების ხელახლა გამოყენება, როდესაც მათი ზედა დონის დამოკიდებულებები იყენებენ rebar3-ს. Rebar-ის კონფიგურაცია, წყაროს/header ფაილები და rebar3-ის შესრულებადი ფაილის თითის ანაბეჭდი მონაწილეობენ გასაღებებში. შეფუთული `ebin/*.app` მეტამონაცემები და პასიური Makefile-ები ასევე მხარდაჭერილია. Rebar-ის კონფიგურაციის სკრიპტები Mix-ის მიერ უკვე შეფასებულია ძიებამდე; მათი წყარო და ეფექტური კონფიგურაცია შედის გასაღებებში. აპლიკაციის წყაროს სკრიპტები (`*.app.src.script`) შეფასდება მოგვიანებით rebar3-ის მიერ და საჭიროებენ აუდიტირებულ ბილდერის კონტრაქტს, ისევე როგორც ბილდის პლაგინები და კომპილაციის ჰუკები. დაკარგული rebar3-ის გამშვები ინსტალირდება თითის ანაბეჭდის აღებამდე, Mix-ის ჩვეულებრივი ინსტალერის გამოყენებით; ცივ მუშაკებს კვლავ სჭირდებათ ამ ინსტალერზე წვდომა.

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

## დამატებითი შემავალი მონაცემების განცხადება

წყაროს ხეები, ჩაკეტილი დამოკიდებულების იდენტობები, ზედა დონის წყაროები, BEAM-ები და რესურსები, დამოკიდებულების runtime/არჩევითი/აპლიკაციის ფლაგები, გადაწყვეტილი აპლიკაციის მეტამონაცემები, ცალსახა ეფექტური აპლიკაციის კონფიგურაცია, კომპილატორის პარამეტრები (მათ შორის lexer-ისა და parser-ის პარამეტრები), Mix-ის გარემო და სამიზნე, და ინსტრუმენტთა ჯაჭვის იდენტობა ავტომატურად შედის. დამოკიდებულებისთვის სპეციფიკური `env:` და `system_env:` შედის გასაღებში და კონფიგურაცია შეფასდება ამ გარემოში. აპლიკაციის ნაგულისხმები მნიშვნელობები შედის წყაროს შემავალი მონაცემების მეშვეობით, არა VM-ის ჩატვირთვის მდგომარეობით.

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

```elixir
cache: [
  inputs: ["schemas", "config/compiler-input.json"],
  env: ["YOUR_COMPILER_OPTION"]
]
```

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

სტანდარტული კომპილატორის/runtime ცვლადები (`ERL_COMPILER_OPTIONS`, `ELIXIR_ERL_OPTIONS`, `ERL_AFLAGS`, `ERL_FLAGS`, `ERL_ZFLAGS`, `SOURCE_DATE_EPOCH`, `ERL_LIBS`, `MIX_PATH` და `MIX_ARCHIVES`) ავტომატურად ფიქსირდება. ინსტრუმენტთა ჯაჭვის იდენტობა მოიცავს Elixir-ის ბილდს, სრულ OTP ვერსიას, როდესაც ხელმისაწვდომია, ERTS-ს, კომპილატორის ბაიტკოდს, OS/ვერსიას, არქიტექტურას, სიტყვის ზომას და ბაიტების თანმიმდევრობას. ეფექტური კონტექსტი ფიქსირდება ყოველ ძიებამდე. თითოეული დამოკიდებულების შემავალი მონაცემების მოდელები შეიძლება გაზიარდეს ერთი მომზადების ფარგლებში ძიების დაგეგმვისთვის; კომპილაცია ასუფთავებს გეგმას და აღდგენა აუქმებს ინსტალირებული აპლიკაციის ჩანაწერებს. ეტაპობრივი ინსტალაცია და გამოქვეყნება ყოველთვის ამოწმებს ახალ შემავალ მონაცემებს ძიების გეგმის ხელახლა გამოყენების გარეშე. ძიების გამოტოვებაც ასევე იღებს ახალ გასაღებს კომპილაციამდე. შეცვლილი შემავალი მონაცემები უარყოფენ ეტაპობრივ წარმატებას, ნაცვლად იმისა, რომ დააინსტალირონ კოდი, რომელიც აგებულია ადრეული შემავალი მონაცემებისთვის.

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

დეტერმინისტული გასაღების კოდირება გამოყოფილია დეტერმინისტული კომპილატორის გამოსავალისგან. თუ ზედა დონის BEAM მეტამონაცემები იცვლება სხვაგვარად იდენტურ ბილდებს შორის Elixir-ის ახალ ვერსიებზე, განიხილეთ `ERL_COMPILER_OPTIONS='[deterministic]'`-ის დაყენება SDK-ის bootstrap-მდე, თესლის ჩასხმამდე და კეშის მოხმარებამდე. გააერთიანეთ ის ნებისმიერ არსებულ კომპილატორის პარამეტრთან და ხელახლა ააგეთ დამოკიდებულების გამოსავალი ერთხელ პარამეტრის შეცვლისას. SDK არ აყენებს მას ავტომატურად; მისი ზუსტი მნიშვნელობა რჩება გასაღების ნაწილად. სრული ზედა დონის ბაიტები კვლავ იჰეშება, არა ნორმალიზდება ან იშლება. ეს არ არის cross-checkout ან ნებისმიერი ბილდერის აღწარმოებადობის გარანტია. კომპილატორის პარამეტრი ასევე ტოვებს წყაროს/პარამეტრებს `module_info(:compile)`-დან, ამიტომ შეამოწმეთ დაფარვა, დებაგინგი და წყაროს აღმოჩენის ინსტრუმენტები მის ათვისებამდე. კომპილატორის ფლაგები არ ასწორებენ დაულაგებელ კომპილაციის დროის გენერატორებს. SDK საჭიროებს Mint 1.10.2 ან უფრო ახალს, მისი უსაფრთხოების უკანაპორტების ჩათვლით. ეს რელიზი ალაგებს რუკებს, რომლებიც გამოიყენება HTTP/2 ფრეიმის ფუნქციების გენერირებისთვის; განაახლეთ ძველი Mint lock ჩანაწერები SDK-ის განახლებისას. სხვა დამოკიდებულებებმა და კომპილატორის გადაცემებმა შეიძლება კვლავ წარმოქმნან ცვალებადი bootstrap BEAM-ები, მაშინაც კი, როდესაც `deterministic` ჩართულია.

Lexer-ისა და parser-ის გამოსავალი განიხილება, როგორც წარმოებული ფაილები მხოლოდ მაშინ, როდესაც ისინი არ არიან ჩაკეტილ Git ხეში ან Hex პაკეტის ფაილის მანიფესტში. მიწოდებული `.erl` ფაილები და გაუმჭვირვალე დირექტორიის/საბმოდულის შინაარსი რჩება ჩვეულებრივ შემავალ მონაცემებად; ხელახლა გენერირებულმა მიწოდებულმა ფაილებმა უნდა გაიარონ იგივე post-staging შემავალი მონაცემების შეჯერება. გენერატორის შაბლონები OTP-ის `parsetools`-დან ასევე შედის ინსტრუმენტთა ჯაჭვის იდენტობაში. შეინარჩუნეთ დამოკიდებულების წყაროს checkouts იზოლირებული პარალელური ბილდების დროს: გენერატორებმა და ნატიურმა ბილდერებმა შეიძლება ჩაწერონ `deps/`-ში. ჩადგმულ/მორგებულ rebar გენერატორის განლაგებებს შეიძლება კვლავ დასჭირდეთ აუდიტირებული `generated` განცხადება.

## ნატიური და მორგებული ბილდერები

აუდიტირებული Mix, rebar3 ან Make ბილდერისთვის განაცხადეთ თითოეული დამოკიდებულების კონტრაქტი:

```elixir
cache: [
  builders: [
    bcrypt_elixir: [
      platform: "build-image@sha256:YOUR_IMMUTABLE_IMAGE_DIGEST",
      outputs: ["priv/bcrypt_nif.so"],
      tools: ["cc", "make"],
      env: ["YOUR_BUILDER_OPTION"]
    ]
  ]
]
```

`platform` განსაზღვრავს თავსებად ნატიურ ბილდის გარემოს. გამოიყენეთ უცვლელი image/toolchain იდენტობა, რომელიც მოიცავს კომპილატორებს, SDK-ებს, სისტემურ სათაურებს და გაზიარებულ ბიბლიოთეკებს, არა ხელახლა გამოსაყენებელი ლეიბლი, როგორიცაა `linux`. Elixir/OTP და ჩვეულებრივი პლატფორმის შემოწმებები კვლავ მოქმედებს. ეს არის ბილდერის ცხადი აუდიტი, არა ნატიური შემავალი მონაცემების ან საჭირო გვერდითი ეფექტების ავტომატური აღმოჩენა. არასწორი ცხადი ბილდერის კონტრაქტები იწვევენ შესწორებად კონფიგურაციის შეცდომას, ნაცვლად იმისა, რომ ჩუმად დატოვონ ქეშირება გამორთული.

`outputs` ჩამოთვლის საჭირო გზებს დამოკიდებულების აპლიკაციის ბილდის დირექტორიასთან მიმართებაში. ჩამოთვალეთ რეალური ბიბლიოთეკები/შესრულებადი ფაილები, რომლებიც საჭიროა runtime-ზე. დაკარგული გამოსავალი იწვევს აღდგენას ან კომპილაციას მაშინაც კი, თუ Mix BEAM-ებს მიმდინარედ თვლის; არასრული snapshot-ები უარყოფილია. განაცხადეთ დამატებითი გარემოს ცვლადები ბილდერის `env`-ით და გარე ფაილები/დირექტორიები მისი `inputs`-ით, მომხმარებელი პროექტის მიმართ. ნატიური გასაღებები ავტომატურად მოიცავს სტანდარტულ ბილდის გარემოს ცვლადებს, როგორიცაა `PATH`, `CC`, `CXX`, `CFLAGS`, `LDFLAGS`, `SDKROOT` და `RUSTFLAGS`, დამოკიდებულების ეფექტური `system_env` გადაფარვების გამოყენებით. ამოხსნილი Mix პროექტის კონფიგურაცია ასევე შედის ნატიური ბილდერის გასაღებებში; გაუმჭვირვალე ფუნქციის მნიშვნელობის მქონე კონფიგურაციის ქეშირება შეუძლებელია.

არააუცილებელი `tools` სახელები იხსნება ამ ეფექტურ `PATH`-ზე; ინსტრუმენტების ფარდობითი გზები ფარდობითია დამოკიდებულების წყაროს დირექტორიასთან მიმართებაში. შესრულებადი ბაიტები და ამოხსნილი გზები შედის გასაღებში, ხოლო ხელმიუწვდომელი განცხადებული ინსტრუმენტები აცილებენ ქეშირებას. გამშვების ან კომპილატორის wrapper-ის fingerprint არ მოიცავს მის SDK-ებს, ქვეპროცესებს ან სისტემურ ბიბლიოთეკებს: უცვლელმა `platform` და დამატებითმა `inputs` უნდა მოიცვან ისინი. `MAKEFLAGS` ინახება უცვლელად, რადგან მორგებულმა ბილდერებმა შეიძლება წაიკითხონ ის. მემკვიდრე GNU make jobserver იდენტიფიკატორებმა შეიძლება გამოიწვიონ უსაფრთხო cache miss-ები გაშვებებს შორის; გამოიყენეთ სტაბილური ბილდის ფლაგები იზოლირებულ cache სამუშაოში, ნაცვლად იმის ვარაუდისა, რომ ეს მნიშვნელობები ამოღებულია გასაღებიდან.

ზოგიერთი ბილდერი აგენერირებს ფაილებს `deps/`-ის ქვეშ, ნაცვლად მხოლოდ `_build/`-ის. ჩამოთვალეთ ეს გზები იმ დამოკიდებულების წყაროს დირექტორიასთან მიმართებაში `generated`-ში, მაგალითად `generated: ["priv/native"]`. მხოლოდ ეს გენერირებული გზებია გამორიცხული წყაროს შემავალი მონაცემებიდან. არ გამორიცხოთ ორიგინალური რესურსები ან წყაროს ფაილები: ისინი უნდა დარჩნენ შემავალ მონაცემებად. გზებია ზუსტი, glob-ების ან ტრავერსის გარეშე. კონტრაქტი, პლატფორმა, დამატებითი შემავალი მონაცემები, გარემოს მნიშვნელობები და ნებისმიერი მორგებული დამოკიდებულების კომპილაციის ბრძანება ყველა მონაწილეობს გასაღებებში. `compile: false` რჩება კომპილაციიდან გამორთვის საშუალებად.

აუდიტირებული snapshot-ები მატერიალიზდება წყაროზე დაფუძნებულ `ebin`, `priv`, `include` და `src` რესურსებს აღდგენილ აპლიკაციაში. ნატიური ბიბლიოთეკები, port შესრულებადი ფაილები, სათაურები და გენერირებული რესურსები ამიტომ უძლებენ ცივ checkout-ს, დამოკიდებულების წყაროების შეცვლის გარეშე. შესრულებადი რეჟიმები და ჩადგმული ფარდობითი რესურსების symlink-ები ინახება; escaping, აბსოლუტური და ციკლური ბმები უარყოფილია. ყველა upstream აპლიკაციის რესურსი შედის downstream გასაღებებში, ჩვეულებრივი `priv` რესურსების და მორგებული გამოსავლის დირექტორიების ჩათვლით, არა მხოლოდ ნატიური ბიბლიოთეკების ან BEAM-ების. კოდი, რომელიც პირდაპირ კითხულობს მწარმოებლის წყაროს გზებს, არ გადაადგილდება; ბილდერებს, რომლებსაც აქვთ სავალდებულო გვერდითი ეფექტები აპლიკაციის არტეფაქტის გარეთ, კვლავ სჭირდებათ ეს ნაბიჯები.

შეინარჩუნეთ მორგებული ბილდერები გამორიცხული, სანამ მათი შემავალი და გამოსავალი მონაცემები არ იქნება აუდიტირებული. კონტრაქტი არ აშორებს ცივ SDK bootstrap კომპილაციას, 64 MiB არტეფაქტის ლიმიტს ან თავსებადი ბილდის გარემოს საჭიროებას.

## გამოყენება checkout გზებზე

Checkout გზები ნაგულისხმევად მონაწილეობენ გასაღებებში. თუ თქვენი დამოკიდებულებები არ ეყრდნობიან მწარმოებლის გზებს, ჩართეთ გამოყენება სხვადასხვა checkout ადგილებს შორის:

```elixir
cache: [portable: true]
```

კონფიგურირებული მნიშვნელობები, რომლებიც შეიცავს checkout გზას, როგორიცაა `config/config.exs`-ში `__DIR__`-დან აგებული გზები, არ ცვლის პორტაბელურ გასაღებებს. ასევე არა ის, თუ სად არის დაინსტალირებული თქვენი Elixir ინსტრუმენტთა ჯაჭვი: არქივები და rebar3 ითვლება მათი შინაარსის მიხედვით.

ქეშირებულ BEAM-ებს ინახავს მწარმოებლის debug/წყაროს გზები და compile-time `__DIR__`, `__ENV__.file` და `File.cwd!()` მნიშვნელობები. პორტაბელური გამოყენება არ წერს მათ ხელახლა. რესურსების ბმები მიუთითებენ მიმდინარე წყაროს checkout-ზე. Upstream BEAM ბაიტები ასევე შედის გასაღებებში და შეიძლება შეიცავდნენ გზებს, ამიტომ გამოყენებამ შეიძლება მოითხოვოს upstream closure-ის აღდგენა იმავე ქეშიდან, ნაცვლად მისი დამოუკიდებლად ხელახლა კომპილირებისა.

## შენახვა და წვდომა

| პარამეტრი | ნაგულისხმევი | მიზანი |
| --- | --- | --- |
| `remote` | `true` | გამოიყენეთ გაზიარებული remote ქეში local miss-ის შემდეგ. |
| `upload` | `true` | გამოაქვეყნეთ ახალი bundles remotely. `false` მაინც საშუალებას აძლევს წაკითხვას და local snapshot-ებს. |
| `path` | Tuist-ის ქეშის დირექტორია, `mix/dependencies/v1`-ის ქვეშ | აირჩიეთ სხვა local საცავი. |
| `endpoint` | აღმოჩენილია ავტომატურად | გადაფარეთ ანგარიშის HTTPS REAPI endpoint. |

`upload: false` აკონტროლებს კლიენტის ქცევას, არა ავტორიზაციას. პროექტის ქეშის ნებართვებს აკონტროლებს სერვერი. სერთიფიკატები, რომლებსაც შეუძლიათ მხოლოდ პროექტის ქეშის წაკითხვა, ავტომატურად ტოვებენ ატვირთვებს. პროექტის `endpoint:` პარამეტრები და აღმოჩენილი endpoints მოითხოვენ HTTPS-ს, loopback (`localhost`, `127.0.0.1`, `::1`) development endpoints-ის გარდა.

არაცარიელი `TUIST_CACHE_ENDPOINT` გადაფარავს როგორც `endpoint:`-ს, ასევე აღმოჩენას. Hosted runners იყენებენ მას მათი private in-cluster ქეშთან მისასვლელად. ეს ოპერატორის მიერ კონტროლირებადი გარემოს გადაფარვა ასევე საშუალებას აძლევს HTTP-ს non-loopback hosts-ზე. HTTP აგზავნის პროექტის მასშტაბის ქეშის token-ს და არტეფაქტებს დაუშიფრავად, ამიტომ გამოიყენეთ ის მხოლოდ სანდო ქსელში. არასწორი გადაფარვა ბრუნდება local snapshot-ებზე აღმოჩენის ცდის გარეშე.

Local snapshot-ები და remote bundles შეზღუდულია 64 MiB-მდე; უფრო დიდი არტეფაქტები კომპილირდება ქეშირების გარეშე. Local საცავს არ აქვს ავტომატური eviction; წაშალეთ მისი შინაარსი საჭიროების შემთხვევაში. Remote არტეფაქტები იყენებენ Kura-ს არსებულ retention, eviction და პროექტის გასუფთავების წესებს.

> [!IMPORTANT]
> კომპილატორის მანიფესტებმა და BEAM-ებმა შეიძლება ჩაასვენონ მწარმოებლის გზები და compile-time მნიშვნელობები, საიდუმლოებების ჩათვლით. პროექტის ქეშის მკითხველებს შეუძლიათ წვდომა ამ არტეფაქტებთან. ქეშის მწერლები არიან სანდო კოდის მწარმოებლები: digest შემოწმებები აფიქსირებენ დაზიანებას, არა მავნე შესრულებად BEAM-ებს. არ გახადოთ ქეშ-ჩაწერის სერთიფიკატები ხელმისაწვდომი არასანდო PR სამუშაოებისთვის ან არ დააკომპილიროთ არასანდო დამოკიდებულებები ამ სერთიფიკატების ხელმისაწვდომობის პირობებში.

## დაკარგული hits-ების პრობლემების მოგვარება

- გაუშვით `mix tuist.setup` პაკეტის დაინსტალირების შემდეგ და დააკომიტეთ გენერირებული Mix კონფიგურაცია. Setup ინარჩუნებს სხვა aliases-ებს და Tuist პარამეტრებს; ის უარყოფს მორგებულ კომპილაციის მოქმედებებს, ნაცვლად მათი ჩუმად წაშლისა.
- შეინარჩუნეთ გენერირებული კომპილაციის alias. პირდაპირმა `mix tuist.compile` task-ების აღმოჩენამ შეიძლება დააკომპილიროს დამოკიდებულებები მანამ, სანამ ქეშირება შეძლებს მათ შემოწმებას.
- უკვე არსებული, ვალიდური გამომავალი ფაილები შერჩეული, მხარდაჭერილი დამოკიდებულებებისთვის ითვლება local hits-ად მიზეზით `up_to_date`. ისინი არ ქვეყნდება რეტროსპექტიულად და არ აქვთ არტეფაქტის გასაღები, გადაცემული ბაიტები, აღდგენის ლატენტობა ან შენახული დროის შეფასება. snapshot-ის აღდგენის შესამოწმებლად, გაასუფთავეთ მხოლოდ მხარდაჭერილი დამოკიდებულების build ბრძანებით `mix deps.clean NAME --build` მას შემდეგ, რაც ის შეავსებს ქეშს, შემდეგ კი ხელახლა დააკომპილირეთ.
- დაამთხვიეთ `MIX_ENV`, `MIX_TARGET`, კომპილატორის პარამეტრები და გამოცხადებული input-ები. გზის ცვლილებები ასევე ცვლის გასაღებებს, თუ portable reuse ჩართული არ არის.
- მხარდაუჭერელი დამოკიდებულებები ჩანს როგორც **Not cached**, არა როგორც misses. ისინი გამოირიცხება hit rate-დან. build-ს, რომელსაც არც lookups აქვს და არც up-to-date local hits, აქვს მიუწვდომელი მაჩვენებელი, არა 0%.
- არარსებული სერთიფიკატები, მიუწვდომელი endpoint-ები და დაზიანებული snapshots ბრუნდებიან კომპილაციაზე. კომპილატორის შეცდომები მაინც აფრუშებენ build-ს.
- CAS ჩანაწერები შეიძლება მოვიდეს build report-ის შემდეგ. განაახლეთ ახლად მიღებული გადაცემების სანახავად. Local hits-ებს და ძველ builds-ებს არ აქვთ remote CAS outputs.

სერვერებს სჭირდებათ compile-report contract `0.2` მხარდაჭერა `up_to_date` local hits-ების ჩასაწერად. თუ უფრო ძველი სერვერი ცალსახად უარყოფს ქეშის მონაცემებს ან სქემის enumeration მნიშვნელობას, პაკეტი ერთხელ ცდის report-ის გაგზავნას ამ ახალი reuse დაკვირვებების გარეშე. კომპილაციის დეტალები და სხვა ქეშის შედეგები ინარჩუნება; ახალი local reuse რჩება მიუწვდომელი სერვერის განახლებამდე. სერვერის წინასწარ განთავსება თავიდან აცილებს ამ დამატებით მოთხოვნას. Contract-ის ვერსია არ აწარმოებს მხარდაჭერის შეთანხმებას და ავტორიზაციის შეცდომები, ტრანსპორტის შეცდომები და სხვა ვალიდაციის შეტყობინებები არ მეორდება. Enumeration შეცდომები არ ასახელებენ მათ ველს ძველ სერვერებზე; შენარჩუნებული არასწორი ველი მაინც ვერ გაივლის ერთადერთ ცდაზე.

## ხელით კომპილაციის ინტეგრაცია

თუ setup ვერ შეცვლის თქვენი პროექტის კონფიგურაციას უსაფრთხოდ, დაამატეთ ეს alias და ეს ფუნქციები თქვენს Mix პროექტის მოდულში ხელით, შეინარჩუნეთ ნებისმიერი მორგებული კომპილაციის მოქმედება:

```elixir
# In aliases/0:
compile: &compile/1

# In the same Mix project module:
defp compile(args) do
  if "--no-compile" not in args do
    compile_tuist_ex()
  end

  Mix.Task.run("deps.loadpaths", ["--no-compile", "--no-deps-check"])
  Mix.Task.run("tuist.compile", args)
end

defp compile_tuist_ex do
  deps =
    ["tuist_ex"]
    |> Mix.Dep.filter_by_name(Mix.Dep.load_and_cache(), include_children: true)
    |> Enum.reject(&(Mix.Dep.ok?(&1) and &1.scm.fetchable?()))
    |> Enum.map(&Atom.to_string(&1.app))

  if deps != [], do: Mix.Task.run("deps.compile", deps)
end
```

ეს ფუნქციები აკომპილირებენ და ტვირთავენ Tuist-ს სხვა დამოკიდებულებებამდე, ცივი პარალელური builds-ების ჩათვლით, და ტოვებენ ამ სამუშაოს, თუ Tuist და მისი დამოკიდებულებები უკვე დაკომპილირებულია ან ბრძანება ეშვება `--no-compile`-ით. იგივე ფუნქციები მუშაობს Hex, Git და path ინსტალაციებთან; script-ის გზა არ არის საჭირო.

თუ თქვენი alias იწყება `deps.compile tuist_ex --include-children`-ით, ყოველი `mix compile` ხელახლა აგებს Tuist-ის დამოკიდებულებებს და შეიძლება ხელახლა დააკომპილიროს თქვენი მთელი პროექტი. გაუშვით `mix tuist.setup` ხელახლა მის ჩასანაცვლებლად.

## როგორ მუშაობს

Elixir ქეშირება იყენებს გაზიარებულ REAPI ActionCache/CAS pipeline-ს, ავტორიზაციას და Bazel-ის მიერ გამოყენებულ Kura-ით ხელმოწერილ ანალიტიკას, არა ცალკე Mix storage service-ს. მოდელირებული input გასაღები მიუთითებს ActionResult-ზე, რომელიც შეიცავს სრული კომპილაციის bundle-ის raw-byte SHA-256 digest-ს. Tuist ამოწმებს მის ფაილებს, აპლიკაციის მეტამონაცემებს, გამოცხადებულ BEAM-ებს და SCM მანიფესტს staged ინსტალაციამდე. დაზიანებული ჩანაწერები კეთდება წარმატებული კომპილაციის შემდეგ.

OTP 28 და უფრო ახალ ვერსიებზე, remote სესიები აწარმოებენ zstd კომპრესიის შეთანხმებას ByteStream გადაცემებისთვის, რომლებიც არიან მინიმუმ 1 KiB. არაკომპრესირებადი uploads, ძველი OTP runtimes და სერვერები კომპრესიის გარეშე იყენებენ identity transport-ს. Digest-ები, არტეფაქტის ლიმიტები და მოხსენებული ბაიტები ეხება არაკომპრესირებულ შინაარსს. დეკოდირებული ბაიტები არიან შეზღუდული და შემოწმებული ინსტალაციამდე. თითოეული დამოკიდებულება რჩება ერთიანი CAS bundle, რაც თავიდან იცილებს per-file ან chunk მოთხოვნებს მცირე არტეფაქტებისთვის.

Remote სერთიფიკატები/კავშირები წყდება lazy-დ; უმოქმედო builds და local hits (უკვე არსებული გამომავალი ფაილების ჩათვლით) არ უკავშირდებიან remote endpoint-ებს. ერთი სესია იხურება ყოველ გასვლაზე, კომპილატორის შეცდომის ჩათვლით. Client RPC-ებს აქვთ 30-წამიანი ვადა. Mix რჩება პასუხისმგებელი lock შემოწმებებზე, local დამოკიდებულების კომპილაციაზე და მხარდაუჭერელ სამუშაოზე.

Dashboard latency/bytes ინარჩუნებს local versus remote provenance-ს და არჩევს მიუწვდომელ მნიშვნელობებს გაზომილი ნულისგან. Remote timing ზომავს client CAS გადაცემებს, ხოლო local timing მოიცავს ვერიფიკაციას და ინსტალაციას; არცერთი არ მოიცავს კომპილაციას. CAS Outputs იყენებს წარმატებულ Kura-ით ხელმოწერილ გადაცემებს, არა local copies ან action-input გასაღებებს. Throughput არის ბაიტები გაყოფილი გაზომილ დროზე; კომპრესირებული ზომები მიუწვდომელია. შეფასებული თავიდან აცილებული კომპილაციის დრო არის მწარმოებლის ორიგინალური კომპილაციის ხანგრძლივობა, არა გაზომილი end-to-end build შენახვა.

დამოუკიდებელი, მზა დამოკიდებულებები იტვირთება ფანჯრებში, მაქსიმუმ ოთხი concurrent მოთხოვნით ერთი და იგივე HTTP/2 კავშირზე. ეს ზღუდავს decoded bundle buffering-ს ოთხ არტეფაქტამდე, თითოეული ექვემდებარება 64 MiB ლიმიტს. გასაღების დაგეგმვა, Mix state და ინსტალაცია რჩება სერიალიზებული. Downstream გასაღებები ელოდებიან upstream არტეფაქტებს; წინასწარ მიღებული ბაიტები იხარჯება მხოლოდ მათი ზუსტი input გასაღების ქვეშ, input-ები ხელახლა მოწმდება remote ინსტალაციამდე. უკვე არსებული გამომავალი ფაილები და local snapshots არ იწვევენ სპეკულაციურ remote მოთხოვნებს. კომპილაცია და uploads რჩება სერიალური შერჩეული cache misses-ებისთვის; concurrency არ არის დაპირება, რომ ყოველი build იქნება უფრო სწრაფი.

## შეუძლია თუ არა ყოველ დამოკიდებულებას გამოტოვოს კომპილაცია?

თავსებადმა hit-მა შეიძლება გამოტოვოს მხარდაჭერილი დამოკიდებულების კომპილაცია, მაგრამ `cache: true` არის fail-open, არა ნულოვანი კომპილაციის გარანტია. არარსებული/evicted ჩანაწერები, მხარდაუჭერელი builders და ცივი SDK bootstrap მაინც შეიძლება დაკომპილირდნენ. მაღალი hit rate მარტო არ ამყარებს wall-clock speedup-ს.

build-once/test-many CI-სთვის, გამოიყენეთ
<.localized_link href="/guides/features/test-sharding/elixir">Elixir test sharding</.localized_link>
ზუსტად მომზადებული build-ის გასანაწილებლად, ნაცვლად იმის მოლოდინისა, რომ ყოველი worker ხელახლა ააგებს მას per-dependency cache hits-დან. სრული build-ის ხელახლა გამოყენება, განსაკუთრებით იმის, რომელიც შეიცავს native libraries-ს, მაინც მოითხოვს თავსებად პლატფორმას, toolchain-ს და კონფიგურაციას. ნებისმიერმა custom build-მა ვერ შეძლებს უსაფრთხოდ გამოტოვოს მისი build ნაბიჯები მათი external inputs, outputs და საჭირო side effects-ების მოდელირების გარეშე.

Elixir-ის კეშის გაფართოებული კონფიგურაცია

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

დამოკიდებულებების შერჩევა#

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

elixir

cache: [exclude: [:a_dependency_with_compile_time_side_effects]]

კეშირების მხოლოდ კონკრეტულ დამოკიდებულებებზე შემოსაზღვრად:

elixir

cache: [dependencies: [:nimble_options, :nimble_parsec]]

dependencies: :all ცალსახად ირჩევს ყველა მხარდაჭერილ დამოკიდებულებას; dependencies: [] არ ირჩევს არცერთს. exclude: უპირატესობა აქვს ნებისმიერ შერჩევასთან მიმართებაში. cache-ის გამოტოვება, ან მისი false ან nil-ზე დაყენება, თიშავს კეშირებას.

მხარდაჭერილი დამოკიდებულებები იტვირთება Hex-ის ან Git-ის მეშვეობით და იყენებენ Mix-ის სტანდარტულ კომპილატორის პაიპლაინს Elixir/Erlang წყაროებით, ან rebar3-ის ჩვეულებრივ სუფთა-BEAM კომპილაციას. Mix-ის დამოკიდებულებებს ასევე შეუძლიათ არტიფაქტების ხელახლა გამოყენება, როდესაც მათი ზედა დონის დამოკიდებულებები იყენებენ rebar3-ს. Rebar-ის კონფიგურაცია, წყაროს/header ფაილები და rebar3-ის შესრულებადი ფაილის თითის ანაბეჭდი მონაწილეობენ გასაღებებში. შეფუთული ebin/*.app მეტამონაცემები და პასიური Makefile-ები ასევე მხარდაჭერილია. Rebar-ის კონფიგურაციის სკრიპტები Mix-ის მიერ უკვე შეფასებულია ძიებამდე; მათი წყარო და ეფექტური კონფიგურაცია შედის გასაღებებში. აპლიკაციის წყაროს სკრიპტები (*.app.src.script) შეფასდება მოგვიანებით rebar3-ის მიერ და საჭიროებენ აუდიტირებულ ბილდერის კონტრაქტს, ისევე როგორც ბილდის პლაგინები და კომპილაციის ჰუკები. დაკარგული rebar3-ის გამშვები ინსტალირდება თითის ანაბეჭდის აღებამდე, Mix-ის ჩვეულებრივი ინსტალერის გამოყენებით; ცივ მუშაკებს კვლავ სჭირდებათ ამ ინსტალერზე წვდომა.

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

დამატებითი შემავალი მონაცემების განცხადება#

წყაროს ხეები, ჩაკეტილი დამოკიდებულების იდენტობები, ზედა დონის წყაროები, BEAM-ები და რესურსები, დამოკიდებულების runtime/არჩევითი/აპლიკაციის ფლაგები, გადაწყვეტილი აპლიკაციის მეტამონაცემები, ცალსახა ეფექტური აპლიკაციის კონფიგურაცია, კომპილატორის პარამეტრები (მათ შორის lexer-ისა და parser-ის პარამეტრები), Mix-ის გარემო და სამიზნე, და ინსტრუმენტთა ჯაჭვის იდენტობა ავტომატურად შედის. დამოკიდებულებისთვის სპეციფიკური env: და system_env: შედის გასაღებში და კონფიგურაცია შეფასდება ამ გარემოში. აპლიკაციის ნაგულისხმები მნიშვნელობები შედის წყაროს შემავალი მონაცემების მეშვეობით, არა VM-ის ჩატვირთვის მდგომარეობით.

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

elixir

cache: [
  inputs: ["schemas", "config/compiler-input.json"],
  env: ["YOUR_COMPILER_OPTION"]
]

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

სტანდარტული კომპილატორის/runtime ცვლადები (ERL_COMPILER_OPTIONS, ELIXIR_ERL_OPTIONS, ERL_AFLAGS, ERL_FLAGS, ERL_ZFLAGS, SOURCE_DATE_EPOCH, ERL_LIBS, MIX_PATH და MIX_ARCHIVES) ავტომატურად ფიქსირდება. ინსტრუმენტთა ჯაჭვის იდენტობა მოიცავს Elixir-ის ბილდს, სრულ OTP ვერსიას, როდესაც ხელმისაწვდომია, ERTS-ს, კომპილატორის ბაიტკოდს, OS/ვერსიას, არქიტექტურას, სიტყვის ზომას და ბაიტების თანმიმდევრობას. ეფექტური კონტექსტი ფიქსირდება ყოველ ძიებამდე. თითოეული დამოკიდებულების შემავალი მონაცემების მოდელები შეიძლება გაზიარდეს ერთი მომზადების ფარგლებში ძიების დაგეგმვისთვის; კომპილაცია ასუფთავებს გეგმას და აღდგენა აუქმებს ინსტალირებული აპლიკაციის ჩანაწერებს. ეტაპობრივი ინსტალაცია და გამოქვეყნება ყოველთვის ამოწმებს ახალ შემავალ მონაცემებს ძიების გეგმის ხელახლა გამოყენების გარეშე. ძიების გამოტოვებაც ასევე იღებს ახალ გასაღებს კომპილაციამდე. შეცვლილი შემავალი მონაცემები უარყოფენ ეტაპობრივ წარმატებას, ნაცვლად იმისა, რომ დააინსტალირონ კოდი, რომელიც აგებულია ადრეული შემავალი მონაცემებისთვის.

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

დეტერმინისტული გასაღების კოდირება გამოყოფილია დეტერმინისტული კომპილატორის გამოსავალისგან. თუ ზედა დონის BEAM მეტამონაცემები იცვლება სხვაგვარად იდენტურ ბილდებს შორის Elixir-ის ახალ ვერსიებზე, განიხილეთ ERL_COMPILER_OPTIONS='[deterministic]'-ის დაყენება SDK-ის bootstrap-მდე, თესლის ჩასხმამდე და კეშის მოხმარებამდე. გააერთიანეთ ის ნებისმიერ არსებულ კომპილატორის პარამეტრთან და ხელახლა ააგეთ დამოკიდებულების გამოსავალი ერთხელ პარამეტრის შეცვლისას. SDK არ აყენებს მას ავტომატურად; მისი ზუსტი მნიშვნელობა რჩება გასაღების ნაწილად. სრული ზედა დონის ბაიტები კვლავ იჰეშება, არა ნორმალიზდება ან იშლება. ეს არ არის cross-checkout ან ნებისმიერი ბილდერის აღწარმოებადობის გარანტია. კომპილატორის პარამეტრი ასევე ტოვებს წყაროს/პარამეტრებს module_info(:compile)-დან, ამიტომ შეამოწმეთ დაფარვა, დებაგინგი და წყაროს აღმოჩენის ინსტრუმენტები მის ათვისებამდე. კომპილატორის ფლაგები არ ასწორებენ დაულაგებელ კომპილაციის დროის გენერატორებს. SDK საჭიროებს Mint 1.10.2 ან უფრო ახალს, მისი უსაფრთხოების უკანაპორტების ჩათვლით. ეს რელიზი ალაგებს რუკებს, რომლებიც გამოიყენება HTTP/2 ფრეიმის ფუნქციების გენერირებისთვის; განაახლეთ ძველი Mint lock ჩანაწერები SDK-ის განახლებისას. სხვა დამოკიდებულებებმა და კომპილატორის გადაცემებმა შეიძლება კვლავ წარმოქმნან ცვალებადი bootstrap BEAM-ები, მაშინაც კი, როდესაც deterministic ჩართულია.

Lexer-ისა და parser-ის გამოსავალი განიხილება, როგორც წარმოებული ფაილები მხოლოდ მაშინ, როდესაც ისინი არ არიან ჩაკეტილ Git ხეში ან Hex პაკეტის ფაილის მანიფესტში. მიწოდებული .erl ფაილები და გაუმჭვირვალე დირექტორიის/საბმოდულის შინაარსი რჩება ჩვეულებრივ შემავალ მონაცემებად; ხელახლა გენერირებულმა მიწოდებულმა ფაილებმა უნდა გაიარონ იგივე post-staging შემავალი მონაცემების შეჯერება. გენერატორის შაბლონები OTP-ის parsetools-დან ასევე შედის ინსტრუმენტთა ჯაჭვის იდენტობაში. შეინარჩუნეთ დამოკიდებულების წყაროს checkouts იზოლირებული პარალელური ბილდების დროს: გენერატორებმა და ნატიურმა ბილდერებმა შეიძლება ჩაწერონ deps/-ში. ჩადგმულ/მორგებულ rebar გენერატორის განლაგებებს შეიძლება კვლავ დასჭირდეთ აუდიტირებული generated განცხადება.

ნატიური და მორგებული ბილდერები#

აუდიტირებული Mix, rebar3 ან Make ბილდერისთვის განაცხადეთ თითოეული დამოკიდებულების კონტრაქტი:

elixir

cache: [
  builders: [
    bcrypt_elixir: [
      platform: "build-image@sha256:YOUR_IMMUTABLE_IMAGE_DIGEST",
      outputs: ["priv/bcrypt_nif.so"],
      tools: ["cc", "make"],
      env: ["YOUR_BUILDER_OPTION"]
    ]
  ]
]

platform განსაზღვრავს თავსებად ნატიურ ბილდის გარემოს. გამოიყენეთ უცვლელი image/toolchain იდენტობა, რომელიც მოიცავს კომპილატორებს, SDK-ებს, სისტემურ სათაურებს და გაზიარებულ ბიბლიოთეკებს, არა ხელახლა გამოსაყენებელი ლეიბლი, როგორიცაა linux. Elixir/OTP და ჩვეულებრივი პლატფორმის შემოწმებები კვლავ მოქმედებს. ეს არის ბილდერის ცხადი აუდიტი, არა ნატიური შემავალი მონაცემების ან საჭირო გვერდითი ეფექტების ავტომატური აღმოჩენა. არასწორი ცხადი ბილდერის კონტრაქტები იწვევენ შესწორებად კონფიგურაციის შეცდომას, ნაცვლად იმისა, რომ ჩუმად დატოვონ ქეშირება გამორთული.

outputs ჩამოთვლის საჭირო გზებს დამოკიდებულების აპლიკაციის ბილდის დირექტორიასთან მიმართებაში. ჩამოთვალეთ რეალური ბიბლიოთეკები/შესრულებადი ფაილები, რომლებიც საჭიროა runtime-ზე. დაკარგული გამოსავალი იწვევს აღდგენას ან კომპილაციას მაშინაც კი, თუ Mix BEAM-ებს მიმდინარედ თვლის; არასრული snapshot-ები უარყოფილია. განაცხადეთ დამატებითი გარემოს ცვლადები ბილდერის env-ით და გარე ფაილები/დირექტორიები მისი inputs-ით, მომხმარებელი პროექტის მიმართ. ნატიური გასაღებები ავტომატურად მოიცავს სტანდარტულ ბილდის გარემოს ცვლადებს, როგორიცაა PATH, CC, CXX, CFLAGS, LDFLAGS, SDKROOT და RUSTFLAGS, დამოკიდებულების ეფექტური system_env გადაფარვების გამოყენებით. ამოხსნილი Mix პროექტის კონფიგურაცია ასევე შედის ნატიური ბილდერის გასაღებებში; გაუმჭვირვალე ფუნქციის მნიშვნელობის მქონე კონფიგურაციის ქეშირება შეუძლებელია.

არააუცილებელი tools სახელები იხსნება ამ ეფექტურ PATH-ზე; ინსტრუმენტების ფარდობითი გზები ფარდობითია დამოკიდებულების წყაროს დირექტორიასთან მიმართებაში. შესრულებადი ბაიტები და ამოხსნილი გზები შედის გასაღებში, ხოლო ხელმიუწვდომელი განცხადებული ინსტრუმენტები აცილებენ ქეშირებას. გამშვების ან კომპილატორის wrapper-ის fingerprint არ მოიცავს მის SDK-ებს, ქვეპროცესებს ან სისტემურ ბიბლიოთეკებს: უცვლელმა platform და დამატებითმა inputs უნდა მოიცვან ისინი. MAKEFLAGS ინახება უცვლელად, რადგან მორგებულმა ბილდერებმა შეიძლება წაიკითხონ ის. მემკვიდრე GNU make jobserver იდენტიფიკატორებმა შეიძლება გამოიწვიონ უსაფრთხო cache miss-ები გაშვებებს შორის; გამოიყენეთ სტაბილური ბილდის ფლაგები იზოლირებულ cache სამუშაოში, ნაცვლად იმის ვარაუდისა, რომ ეს მნიშვნელობები ამოღებულია გასაღებიდან.

ზოგიერთი ბილდერი აგენერირებს ფაილებს deps/-ის ქვეშ, ნაცვლად მხოლოდ _build/-ის. ჩამოთვალეთ ეს გზები იმ დამოკიდებულების წყაროს დირექტორიასთან მიმართებაში generated-ში, მაგალითად generated: ["priv/native"]. მხოლოდ ეს გენერირებული გზებია გამორიცხული წყაროს შემავალი მონაცემებიდან. არ გამორიცხოთ ორიგინალური რესურსები ან წყაროს ფაილები: ისინი უნდა დარჩნენ შემავალ მონაცემებად. გზებია ზუსტი, glob-ების ან ტრავერსის გარეშე. კონტრაქტი, პლატფორმა, დამატებითი შემავალი მონაცემები, გარემოს მნიშვნელობები და ნებისმიერი მორგებული დამოკიდებულების კომპილაციის ბრძანება ყველა მონაწილეობს გასაღებებში. compile: false რჩება კომპილაციიდან გამორთვის საშუალებად.

აუდიტირებული snapshot-ები მატერიალიზდება წყაროზე დაფუძნებულ ebin, priv, include და src რესურსებს აღდგენილ აპლიკაციაში. ნატიური ბიბლიოთეკები, port შესრულებადი ფაილები, სათაურები და გენერირებული რესურსები ამიტომ უძლებენ ცივ checkout-ს, დამოკიდებულების წყაროების შეცვლის გარეშე. შესრულებადი რეჟიმები და ჩადგმული ფარდობითი რესურსების symlink-ები ინახება; escaping, აბსოლუტური და ციკლური ბმები უარყოფილია. ყველა upstream აპლიკაციის რესურსი შედის downstream გასაღებებში, ჩვეულებრივი priv რესურსების და მორგებული გამოსავლის დირექტორიების ჩათვლით, არა მხოლოდ ნატიური ბიბლიოთეკების ან BEAM-ების. კოდი, რომელიც პირდაპირ კითხულობს მწარმოებლის წყაროს გზებს, არ გადაადგილდება; ბილდერებს, რომლებსაც აქვთ სავალდებულო გვერდითი ეფექტები აპლიკაციის არტეფაქტის გარეთ, კვლავ სჭირდებათ ეს ნაბიჯები.

შეინარჩუნეთ მორგებული ბილდერები გამორიცხული, სანამ მათი შემავალი და გამოსავალი მონაცემები არ იქნება აუდიტირებული. კონტრაქტი არ აშორებს ცივ SDK bootstrap კომპილაციას, 64 MiB არტეფაქტის ლიმიტს ან თავსებადი ბილდის გარემოს საჭიროებას.

გამოყენება checkout გზებზე#

Checkout გზები ნაგულისხმევად მონაწილეობენ გასაღებებში. თუ თქვენი დამოკიდებულებები არ ეყრდნობიან მწარმოებლის გზებს, ჩართეთ გამოყენება სხვადასხვა checkout ადგილებს შორის:

elixir

cache: [portable: true]

კონფიგურირებული მნიშვნელობები, რომლებიც შეიცავს checkout გზას, როგორიცაა config/config.exs-ში __DIR__-დან აგებული გზები, არ ცვლის პორტაბელურ გასაღებებს. ასევე არა ის, თუ სად არის დაინსტალირებული თქვენი Elixir ინსტრუმენტთა ჯაჭვი: არქივები და rebar3 ითვლება მათი შინაარსის მიხედვით.

ქეშირებულ BEAM-ებს ინახავს მწარმოებლის debug/წყაროს გზები და compile-time __DIR__, __ENV__.file და File.cwd!() მნიშვნელობები. პორტაბელური გამოყენება არ წერს მათ ხელახლა. რესურსების ბმები მიუთითებენ მიმდინარე წყაროს checkout-ზე. Upstream BEAM ბაიტები ასევე შედის გასაღებებში და შეიძლება შეიცავდნენ გზებს, ამიტომ გამოყენებამ შეიძლება მოითხოვოს upstream closure-ის აღდგენა იმავე ქეშიდან, ნაცვლად მისი დამოუკიდებლად ხელახლა კომპილირებისა.

შენახვა და წვდომა#

პარამეტრი	ნაგულისხმევი	მიზანი
`remote`	`true`	გამოიყენეთ გაზიარებული remote ქეში local miss-ის შემდეგ.
`upload`	`true`	გამოაქვეყნეთ ახალი bundles remotely. `false` მაინც საშუალებას აძლევს წაკითხვას და local snapshot-ებს.
`path`	Tuist-ის ქეშის დირექტორია, `mix/dependencies/v1`-ის ქვეშ	აირჩიეთ სხვა local საცავი.
`endpoint`	აღმოჩენილია ავტომატურად	გადაფარეთ ანგარიშის HTTPS REAPI endpoint.

upload: false აკონტროლებს კლიენტის ქცევას, არა ავტორიზაციას. პროექტის ქეშის ნებართვებს აკონტროლებს სერვერი. სერთიფიკატები, რომლებსაც შეუძლიათ მხოლოდ პროექტის ქეშის წაკითხვა, ავტომატურად ტოვებენ ატვირთვებს. პროექტის endpoint: პარამეტრები და აღმოჩენილი endpoints მოითხოვენ HTTPS-ს, loopback (localhost, 127.0.0.1, ::1) development endpoints-ის გარდა.

არაცარიელი TUIST_CACHE_ENDPOINT გადაფარავს როგორც endpoint:-ს, ასევე აღმოჩენას. Hosted runners იყენებენ მას მათი private in-cluster ქეშთან მისასვლელად. ეს ოპერატორის მიერ კონტროლირებადი გარემოს გადაფარვა ასევე საშუალებას აძლევს HTTP-ს non-loopback hosts-ზე. HTTP აგზავნის პროექტის მასშტაბის ქეშის token-ს და არტეფაქტებს დაუშიფრავად, ამიტომ გამოიყენეთ ის მხოლოდ სანდო ქსელში. არასწორი გადაფარვა ბრუნდება local snapshot-ებზე აღმოჩენის ცდის გარეშე.

Local snapshot-ები და remote bundles შეზღუდულია 64 MiB-მდე; უფრო დიდი არტეფაქტები კომპილირდება ქეშირების გარეშე. Local საცავს არ აქვს ავტომატური eviction; წაშალეთ მისი შინაარსი საჭიროების შემთხვევაში. Remote არტეფაქტები იყენებენ Kura-ს არსებულ retention, eviction და პროექტის გასუფთავების წესებს.

Important

კომპილატორის მანიფესტებმა და BEAM-ებმა შეიძლება ჩაასვენონ მწარმოებლის გზები და compile-time მნიშვნელობები, საიდუმლოებების ჩათვლით. პროექტის ქეშის მკითხველებს შეუძლიათ წვდომა ამ არტეფაქტებთან. ქეშის მწერლები არიან სანდო კოდის მწარმოებლები: digest შემოწმებები აფიქსირებენ დაზიანებას, არა მავნე შესრულებად BEAM-ებს. არ გახადოთ ქეშ-ჩაწერის სერთიფიკატები ხელმისაწვდომი არასანდო PR სამუშაოებისთვის ან არ დააკომპილიროთ არასანდო დამოკიდებულებები ამ სერთიფიკატების ხელმისაწვდომობის პირობებში.

დაკარგული hits-ების პრობლემების მოგვარება#

გაუშვით mix tuist.setup პაკეტის დაინსტალირების შემდეგ და დააკომიტეთ გენერირებული Mix კონფიგურაცია. Setup ინარჩუნებს სხვა aliases-ებს და Tuist პარამეტრებს; ის უარყოფს მორგებულ კომპილაციის მოქმედებებს, ნაცვლად მათი ჩუმად წაშლისა.
შეინარჩუნეთ გენერირებული კომპილაციის alias. პირდაპირმა mix tuist.compile task-ების აღმოჩენამ შეიძლება დააკომპილიროს დამოკიდებულებები მანამ, სანამ ქეშირება შეძლებს მათ შემოწმებას.
უკვე არსებული, ვალიდური გამომავალი ფაილები შერჩეული, მხარდაჭერილი დამოკიდებულებებისთვის ითვლება local hits-ად მიზეზით up_to_date. ისინი არ ქვეყნდება რეტროსპექტიულად და არ აქვთ არტეფაქტის გასაღები, გადაცემული ბაიტები, აღდგენის ლატენტობა ან შენახული დროის შეფასება. snapshot-ის აღდგენის შესამოწმებლად, გაასუფთავეთ მხოლოდ მხარდაჭერილი დამოკიდებულების build ბრძანებით mix deps.clean NAME --build მას შემდეგ, რაც ის შეავსებს ქეშს, შემდეგ კი ხელახლა დააკომპილირეთ.
დაამთხვიეთ MIX_ENV, MIX_TARGET, კომპილატორის პარამეტრები და გამოცხადებული input-ები. გზის ცვლილებები ასევე ცვლის გასაღებებს, თუ portable reuse ჩართული არ არის.
მხარდაუჭერელი დამოკიდებულებები ჩანს როგორც Not cached, არა როგორც misses. ისინი გამოირიცხება hit rate-დან. build-ს, რომელსაც არც lookups აქვს და არც up-to-date local hits, აქვს მიუწვდომელი მაჩვენებელი, არა 0%.
არარსებული სერთიფიკატები, მიუწვდომელი endpoint-ები და დაზიანებული snapshots ბრუნდებიან კომპილაციაზე. კომპილატორის შეცდომები მაინც აფრუშებენ build-ს.
CAS ჩანაწერები შეიძლება მოვიდეს build report-ის შემდეგ. განაახლეთ ახლად მიღებული გადაცემების სანახავად. Local hits-ებს და ძველ builds-ებს არ აქვთ remote CAS outputs.

სერვერებს სჭირდებათ compile-report contract 0.2 მხარდაჭერა up_to_date local hits-ების ჩასაწერად. თუ უფრო ძველი სერვერი ცალსახად უარყოფს ქეშის მონაცემებს ან სქემის enumeration მნიშვნელობას, პაკეტი ერთხელ ცდის report-ის გაგზავნას ამ ახალი reuse დაკვირვებების გარეშე. კომპილაციის დეტალები და სხვა ქეშის შედეგები ინარჩუნება; ახალი local reuse რჩება მიუწვდომელი სერვერის განახლებამდე. სერვერის წინასწარ განთავსება თავიდან აცილებს ამ დამატებით მოთხოვნას. Contract-ის ვერსია არ აწარმოებს მხარდაჭერის შეთანხმებას და ავტორიზაციის შეცდომები, ტრანსპორტის შეცდომები და სხვა ვალიდაციის შეტყობინებები არ მეორდება. Enumeration შეცდომები არ ასახელებენ მათ ველს ძველ სერვერებზე; შენარჩუნებული არასწორი ველი მაინც ვერ გაივლის ერთადერთ ცდაზე.

ხელით კომპილაციის ინტეგრაცია#

თუ setup ვერ შეცვლის თქვენი პროექტის კონფიგურაციას უსაფრთხოდ, დაამატეთ ეს alias და ეს ფუნქციები თქვენს Mix პროექტის მოდულში ხელით, შეინარჩუნეთ ნებისმიერი მორგებული კომპილაციის მოქმედება:

elixir

# In aliases/0:
compile: &compile/1

# In the same Mix project module:
defp compile(args) do
  if "--no-compile" not in args do
    compile_tuist_ex()
  end

  Mix.Task.run("deps.loadpaths", ["--no-compile", "--no-deps-check"])
  Mix.Task.run("tuist.compile", args)
end

defp compile_tuist_ex do
  deps =
    ["tuist_ex"]
    |> Mix.Dep.filter_by_name(Mix.Dep.load_and_cache(), include_children: true)
    |> Enum.reject(&(Mix.Dep.ok?(&1) and &1.scm.fetchable?()))
    |> Enum.map(&Atom.to_string(&1.app))

  if deps != [], do: Mix.Task.run("deps.compile", deps)
end

ეს ფუნქციები აკომპილირებენ და ტვირთავენ Tuist-ს სხვა დამოკიდებულებებამდე, ცივი პარალელური builds-ების ჩათვლით, და ტოვებენ ამ სამუშაოს, თუ Tuist და მისი დამოკიდებულებები უკვე დაკომპილირებულია ან ბრძანება ეშვება --no-compile-ით. იგივე ფუნქციები მუშაობს Hex, Git და path ინსტალაციებთან; script-ის გზა არ არის საჭირო.

თუ თქვენი alias იწყება deps.compile tuist_ex --include-children-ით, ყოველი mix compile ხელახლა აგებს Tuist-ის დამოკიდებულებებს და შეიძლება ხელახლა დააკომპილიროს თქვენი მთელი პროექტი. გაუშვით mix tuist.setup ხელახლა მის ჩასანაცვლებლად.

როგორ მუშაობს#

Elixir ქეშირება იყენებს გაზიარებულ REAPI ActionCache/CAS pipeline-ს, ავტორიზაციას და Bazel-ის მიერ გამოყენებულ Kura-ით ხელმოწერილ ანალიტიკას, არა ცალკე Mix storage service-ს. მოდელირებული input გასაღები მიუთითებს ActionResult-ზე, რომელიც შეიცავს სრული კომპილაციის bundle-ის raw-byte SHA-256 digest-ს. Tuist ამოწმებს მის ფაილებს, აპლიკაციის მეტამონაცემებს, გამოცხადებულ BEAM-ებს და SCM მანიფესტს staged ინსტალაციამდე. დაზიანებული ჩანაწერები კეთდება წარმატებული კომპილაციის შემდეგ.

OTP 28 და უფრო ახალ ვერსიებზე, remote სესიები აწარმოებენ zstd კომპრესიის შეთანხმებას ByteStream გადაცემებისთვის, რომლებიც არიან მინიმუმ 1 KiB. არაკომპრესირებადი uploads, ძველი OTP runtimes და სერვერები კომპრესიის გარეშე იყენებენ identity transport-ს. Digest-ები, არტეფაქტის ლიმიტები და მოხსენებული ბაიტები ეხება არაკომპრესირებულ შინაარსს. დეკოდირებული ბაიტები არიან შეზღუდული და შემოწმებული ინსტალაციამდე. თითოეული დამოკიდებულება რჩება ერთიანი CAS bundle, რაც თავიდან იცილებს per-file ან chunk მოთხოვნებს მცირე არტეფაქტებისთვის.

Remote სერთიფიკატები/კავშირები წყდება lazy-დ; უმოქმედო builds და local hits (უკვე არსებული გამომავალი ფაილების ჩათვლით) არ უკავშირდებიან remote endpoint-ებს. ერთი სესია იხურება ყოველ გასვლაზე, კომპილატორის შეცდომის ჩათვლით. Client RPC-ებს აქვთ 30-წამიანი ვადა. Mix რჩება პასუხისმგებელი lock შემოწმებებზე, local დამოკიდებულების კომპილაციაზე და მხარდაუჭერელ სამუშაოზე.

Dashboard latency/bytes ინარჩუნებს local versus remote provenance-ს და არჩევს მიუწვდომელ მნიშვნელობებს გაზომილი ნულისგან. Remote timing ზომავს client CAS გადაცემებს, ხოლო local timing მოიცავს ვერიფიკაციას და ინსტალაციას; არცერთი არ მოიცავს კომპილაციას. CAS Outputs იყენებს წარმატებულ Kura-ით ხელმოწერილ გადაცემებს, არა local copies ან action-input გასაღებებს. Throughput არის ბაიტები გაყოფილი გაზომილ დროზე; კომპრესირებული ზომები მიუწვდომელია. შეფასებული თავიდან აცილებული კომპილაციის დრო არის მწარმოებლის ორიგინალური კომპილაციის ხანგრძლივობა, არა გაზომილი end-to-end build შენახვა.

დამოუკიდებელი, მზა დამოკიდებულებები იტვირთება ფანჯრებში, მაქსიმუმ ოთხი concurrent მოთხოვნით ერთი და იგივე HTTP/2 კავშირზე. ეს ზღუდავს decoded bundle buffering-ს ოთხ არტეფაქტამდე, თითოეული ექვემდებარება 64 MiB ლიმიტს. გასაღების დაგეგმვა, Mix state და ინსტალაცია რჩება სერიალიზებული. Downstream გასაღებები ელოდებიან upstream არტეფაქტებს; წინასწარ მიღებული ბაიტები იხარჯება მხოლოდ მათი ზუსტი input გასაღების ქვეშ, input-ები ხელახლა მოწმდება remote ინსტალაციამდე. უკვე არსებული გამომავალი ფაილები და local snapshots არ იწვევენ სპეკულაციურ remote მოთხოვნებს. კომპილაცია და uploads რჩება სერიალური შერჩეული cache misses-ებისთვის; concurrency არ არის დაპირება, რომ ყოველი build იქნება უფრო სწრაფი.

შეუძლია თუ არა ყოველ დამოკიდებულებას გამოტოვოს კომპილაცია?#

თავსებადმა hit-მა შეიძლება გამოტოვოს მხარდაჭერილი დამოკიდებულების კომპილაცია, მაგრამ cache: true არის fail-open, არა ნულოვანი კომპილაციის გარანტია. არარსებული/evicted ჩანაწერები, მხარდაუჭერელი builders და ცივი SDK bootstrap მაინც შეიძლება დაკომპილირდნენ. მაღალი hit rate მარტო არ ამყარებს wall-clock speedup-ს.

build-once/test-many CI-სთვის, გამოიყენეთ

Elixir test sharding

ზუსტად მომზადებული build-ის გასანაწილებლად, ნაცვლად იმის მოლოდინისა, რომ ყოველი worker ხელახლა ააგებს მას per-dependency cache hits-დან. სრული build-ის ხელახლა გამოყენება, განსაკუთრებით იმის, რომელიც შეიცავს native libraries-ს, მაინც მოითხოვს თავსებად პლატფორმას, toolchain-ს და კონფიგურაციას. ნებისმიერმა custom build-მა ვერ შეძლებს უსაფრთხოდ გამოტოვოს მისი build ნაბიჯები მათი external inputs, outputs და საჭირო side effects-ების მოდელირების გარეშე.