# Gradle-ის პროექტი {#gradle-project}

::: code-group

```text [Agent prompt]
Help me get started with Tuist. Follow the setup at:
https://tuist.dev/en/docs/guides/get-started/gradle-project
```

:::

მიჰყევით ამ გზას, რათა არსებული Gradle-ის პროექტი Tuist-ზე მიმართოთ. `dev.tuist` Gradle-ის პლაგინი აკავშირებს Gradle-ის ლოკალურ ბილდის ქეშს Tuist-ის დისტანციურ ქეშთან და ტვირთავს ბილდისა და ტესტების მონაცემებს დაფარდაზე, ერთი `./gradlew` ბრძანებაც კი შეუცვლელად.

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

## წინაპირობები

- Gradle-ის პროექტი `settings.gradle.kts`-ით (ან `settings.gradle`-ით).
- <.localized_link href="/guides/install-tuist">Tuist-ის ბრძანების ხაზის ინტერფეისი</.localized_link>.

## პროექტის დაკავშირება

Gradle-ის პროექტის ფესვიდან გაუშვით `tuist init`. აირჩიეთ **Gradle-ის პროექტის ინტეგრაცია**, შემდეგ გაიარეთ ავტორიზაცია ბრაუზერში და აირჩიეთ ის ანგარიში, რომელმაც უნდა ფლობდეს პროექტს.

```bash
tuist init
```

თუ ამას კოდირების აგენტის ან სკრიპტის საშუალებით აკეთებთ, ჯერ გაუშვით `tuist auth login` (ბრაუზერის ნაკადი ელოდება Enter-ის დაჭერას), შემდეგ გამოიყენეთ არაინტერაქტიული ფორმა:

```bash
tuist init --build-system gradle --name <project-handle> --account <account>
```

Tuist წერს `tuist.toml`-ს რეპოზიტორიის ფესვში პროექტის სახელით და ბეჭდავს `plugins { ... }` ბლოკს. ჩასვით ის `settings.gradle.kts`-ის თავში:

```kotlin
plugins {
    id("dev.tuist") version "0.18.1"
}
```


შეამოწმეთ `./gradlew help`-ით. Gradle უნდა ჩაიტვირთოს შეცდომების გარეშე. თუ პლაგინს ვერ პოულობს, დარწმუნდით, რომ ბლოკი `settings.gradle.kts`-შია და არა `build.gradle.kts`-ში.

ქვემოთ მოცემული ყველაფერი არჩევითი და დამოუკიდებელია.

## დისტანციური ბილდის ქეში

Gradle-ის ლოკალური ბილდის ქეში ინახავს ამოცანების გამომავალ მონაცემებს იმ მანქანაზე, რომელმაც ისინი წარმოქმნა. ერთი და იგივე ბრენჩზე მყოფი ორი დეველოპერი ეხება ქეშს საკუთარ `~/.gradle`-ში და არა ერთმანეთისაში, ხოლო CI ყოველ ჯობზე ახალ, ცარიელ ქეშს ეხება.

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

```properties
org.gradle.caching=true
```

შემდეგ ააწყვეთ ორ გარემოში:

```bash
./gradlew clean build --build-cache --info
```

ქეშირებადი ამოცანები მეორე გაშვებაზე ანგარიშობენ `FROM-CACHE`-ს. გახსენით **ქეში** დაფარდაზე, რათა დროთა განმავლობაში ნახოთ მოხვედრის მაჩვენებლები.

## ბილდის ინსაიტები

Gradle ასხივებს ამოცანების დროებს ბილდის ბოლოს და `--profile`-ით წერს თითოეული ბილდის HTML ანგარიშს. არცერთი არ აჯამებს გაშვებებს შორის. ამოცანა, რომელიც კომიტების სერიის განმავლობაში გახდა უფრო ნელი, ნებისმიერი ერთი ბილდის ანგარიშზე ისევე გამოიყურება, როგორც ყოველთვის.

`dev.tuist` პლაგინი ავტომატურად ტვირთავს თითოეული ბილდის ამოცანის დროებს დაფარდაზე, როგორც კი პლაგინი გამოიყენება. დამატებითი კონფიგურაცია არ არის საჭირო. გახსენით **ბილდები** დაფარდაზე თქვენი შემდეგი `./gradlew build`-ის შემდეგ, რათა ნახოთ ტენდენცია.

## ტესტების ინსაიტები

Gradle-ის ტესტების ანგარიშები თითოეული ბილდისთვის ინახება `build/reports/tests/`-ის ქვეშ. ტესტი, რომელიც პერიოდულად მარცხდება ათი CI გაშვების განმავლობაში, ნებისმიერ კონკრეტულ ანგარიშში ისე გამოიყურება, როგორც სტაბილური ტესტი, რომელიც ერთხელ შემთხვევით ჩავარდა.

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

პლაგინი ასევე მხარდაჭერს **სტრეს-ტესტირების რეჟიმს**, რომელიც ხელახლა უშვებს ბილდის მიერ შემოტანილ ტესტის საქმეებს და მონიშნავს ნებისმიერს, რომელიც არასტაბილურად აღმოჩნდება, სანამ ისინი ძირითად ბრენჩში მოხვდებიან. დაამატეთ ის `tuist` გაფართოებაში `settings.gradle.kts`-ში:

```kotlin
tuist {
    stressNewTests {
        mode = "report" // or "enforce"
    }
}
```

## ბანდლის ინსაიტები

Android Gradle Plugin ანგარიშობს წარმოქმნილი `.aab`-ის ზომას ბილდის გამომავალ მონაცემებში. ეს რიცხვი ქრება ბრენჩთან ერთად და ზომების შედარება რელიზებს შორის ხელით შესრულებული აღრიცხვის სამუშაოა. Play Console ანგარიშობს იმავე რიცხვებს, მაგრამ მხოლოდ არტიფაქტის ატვირთვის შემდეგ.

ბანდლის ინსაიტები იწერს ინსტალაციისა და ჩამოტვირთვის ზომებს თითოეული `.aab`-ისთვის (რეკომენდებული) ან `.apk`-ისთვის და შეუძლია PR-ის შემოწმების ჩავარდნა, როდესაც ბრენჩის ზღვარი ირღვევა. დაამატეთ ეს თქვენს CI-ში ბილდის ნაბიჯის შემდეგ:

```bash
tuist inspect bundle App.aab
```

გახსენით **ბანდლის ინსაიტები → Android** დაფარდაზე, რათა ნახოთ ტენდენცია და დააკონფიგურიროთ ზღვრები.

## პრევიუები

Play Console-ის შიდა ტესტის ტრეკი ყოველ გაზიარებაზე ამატებს გადახედვისა და გავრცელების დაყოვნებას. raw `.apk`-ის Slack-ით ან ელფოსტით გაგზავნა უფრო სწრაფია, მაგრამ კარგავს იმის თვალყურის დევნას, თუ რომელ ბილდს ეხება კონკრეტული შეტყობინება.

პლაგინს შეუძლია პირდაპირ ააწყოს და გამოაქვეყნოს აპლიკაციის ვარიანტი, ცალკე CLI ატვირთვის გარეშე:

```bash
./gradlew :app:tuistShareDebug --track nightly
```

`tuistShare<Variant>` ამოცანის მოთხოვნა ანიჭებს იმ გამოძახებას გამოქვეყნების უფლებას; ჩვეულებრივი ბილდები არასდროს ტვირთავენ პრევიუებს. იხილეთ <.localized_link href="/guides/features/previews/gradle">Gradle პრევიუები</.localized_link> მხარდაჭერილი APK-ების, ხელმოწერისა და ინსტალაციისთვის.

## გუნდის ჩართვა

ქეშის მოხვედრები, ინსაიტები და სტრეს-ტესტირება ყველა იზრდება პროექტთან დაკავშირებული ადამიანების რაოდენობის მიხედვით. მიიწვიეთ თქვენი გუნდის წევრები ორგანიზაციაში დაფარდის ანგარიშის პარამეტრებიდან და დააყენეთ <.localized_link href="/guides/integrations/authentication/sso">ერთჯერადი შესვლა</.localized_link> (Google, Okta, Microsoft), რათა დარეგისტრირება იყოს ერთი დაწკაპუნება და არა თითოეული პირისთვის `tuist auth login`.

CI-ისთვის არ გამოიყენოთ პირადი შესვლა. გაიარეთ ავტორიზაცია თქვენი CI პროვაიდერის OIDC იდენტობით, ან შექმენით ანგარიშის ტოკენი დაფარდაზე **CI** პრესეტით და დააყენეთ ის როგორც `TUIST_TOKEN`. იხილეთ <.localized_link href="/guides/server/authentication#gradle-plugin-authentication">Gradle პლაგინის ავტორიზაცია</.localized_link>.

## პლაგინის სრული ცნობარი

აქ მოცემული ყველაფერი არის მინიმუმი, რათა მიიღოთ სარგებელი Tuist-ისგან Gradle-ის პროექტზე. `tuist` გაფართოების ბლოკის, `stressNewTests` რეჟიმისა და CI ავტორიზაციის კონფიგურაციის პარამეტრები მოცემულია [Gradle პლაგინის ინსტალაცია](https://tuist.dev/en/docs/guides/install-gradle-plugin) ცნობარში.

Gradle-ის პროექტი

plaintext

Help me get started with Tuist. Follow the setup at:
https://tuist.dev/en/docs/guides/get-started/gradle-project

მიჰყევით ამ გზას, რათა არსებული Gradle-ის პროექტი Tuist-ზე მიმართოთ. dev.tuist Gradle-ის პლაგინი აკავშირებს Gradle-ის ლოკალურ ბილდის ქეშს Tuist-ის დისტანციურ ქეშთან და ტვირთავს ბილდისა და ტესტების მონაცემებს დაფარდაზე, ერთი ./gradlew ბრძანებაც კი შეუცვლელად.

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

წინაპირობები#

Gradle-ის პროექტი settings.gradle.kts-ით (ან settings.gradle-ით).
Tuist-ის ბრძანების ხაზის ინტერფეისი.

პროექტის დაკავშირება#

Gradle-ის პროექტის ფესვიდან გაუშვით tuist init. აირჩიეთ Gradle-ის პროექტის ინტეგრაცია, შემდეგ გაიარეთ ავტორიზაცია ბრაუზერში და აირჩიეთ ის ანგარიში, რომელმაც უნდა ფლობდეს პროექტს.

bash

tuist init

თუ ამას კოდირების აგენტის ან სკრიპტის საშუალებით აკეთებთ, ჯერ გაუშვით tuist auth login (ბრაუზერის ნაკადი ელოდება Enter-ის დაჭერას), შემდეგ გამოიყენეთ არაინტერაქტიული ფორმა:

bash

tuist init --build-system gradle --name <project-handle> --account <account>

Tuist წერს tuist.toml-ს რეპოზიტორიის ფესვში პროექტის სახელით და ბეჭდავს plugins { ... } ბლოკს. ჩასვით ის settings.gradle.kts-ის თავში:

kotlin

plugins {
    id("dev.tuist") version "0.18.1"
}

შეამოწმეთ ./gradlew help-ით. Gradle უნდა ჩაიტვირთოს შეცდომების გარეშე. თუ პლაგინს ვერ პოულობს, დარწმუნდით, რომ ბლოკი settings.gradle.kts-შია და არა build.gradle.kts-ში.

ქვემოთ მოცემული ყველაფერი არჩევითი და დამოუკიდებელია.

დისტანციური ბილდის ქეში#

Gradle-ის ლოკალური ბილდის ქეში ინახავს ამოცანების გამომავალ მონაცემებს იმ მანქანაზე, რომელმაც ისინი წარმოქმნა. ერთი და იგივე ბრენჩზე მყოფი ორი დეველოპერი ეხება ქეშს საკუთარ ~/.gradle-ში და არა ერთმანეთისაში, ხოლო CI ყოველ ჯობზე ახალ, ცარიელ ქეშს ეხება.

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

plaintext

org.gradle.caching=true

შემდეგ ააწყვეთ ორ გარემოში:

bash

./gradlew clean build --build-cache --info

ქეშირებადი ამოცანები მეორე გაშვებაზე ანგარიშობენ FROM-CACHE-ს. გახსენით ქეში დაფარდაზე, რათა დროთა განმავლობაში ნახოთ მოხვედრის მაჩვენებლები.

ბილდის ინსაიტები#

Gradle ასხივებს ამოცანების დროებს ბილდის ბოლოს და --profile-ით წერს თითოეული ბილდის HTML ანგარიშს. არცერთი არ აჯამებს გაშვებებს შორის. ამოცანა, რომელიც კომიტების სერიის განმავლობაში გახდა უფრო ნელი, ნებისმიერი ერთი ბილდის ანგარიშზე ისევე გამოიყურება, როგორც ყოველთვის.

dev.tuist პლაგინი ავტომატურად ტვირთავს თითოეული ბილდის ამოცანის დროებს დაფარდაზე, როგორც კი პლაგინი გამოიყენება. დამატებითი კონფიგურაცია არ არის საჭირო. გახსენით ბილდები დაფარდაზე თქვენი შემდეგი ./gradlew build-ის შემდეგ, რათა ნახოთ ტენდენცია.

ტესტების ინსაიტები#

Gradle-ის ტესტების ანგარიშები თითოეული ბილდისთვის ინახება build/reports/tests/-ის ქვეშ. ტესტი, რომელიც პერიოდულად მარცხდება ათი CI გაშვების განმავლობაში, ნებისმიერ კონკრეტულ ანგარიშში ისე გამოიყურება, როგორც სტაბილური ტესტი, რომელიც ერთხელ შემთხვევით ჩავარდა.

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

პლაგინი ასევე მხარდაჭერს სტრეს-ტესტირების რეჟიმს, რომელიც ხელახლა უშვებს ბილდის მიერ შემოტანილ ტესტის საქმეებს და მონიშნავს ნებისმიერს, რომელიც არასტაბილურად აღმოჩნდება, სანამ ისინი ძირითად ბრენჩში მოხვდებიან. დაამატეთ ის tuist გაფართოებაში settings.gradle.kts-ში:

kotlin

tuist {
    stressNewTests {
        mode = "report" // or "enforce"
    }
}

ბანდლის ინსაიტები#

Android Gradle Plugin ანგარიშობს წარმოქმნილი .aab-ის ზომას ბილდის გამომავალ მონაცემებში. ეს რიცხვი ქრება ბრენჩთან ერთად და ზომების შედარება რელიზებს შორის ხელით შესრულებული აღრიცხვის სამუშაოა. Play Console ანგარიშობს იმავე რიცხვებს, მაგრამ მხოლოდ არტიფაქტის ატვირთვის შემდეგ.

ბანდლის ინსაიტები იწერს ინსტალაციისა და ჩამოტვირთვის ზომებს თითოეული .aab-ისთვის (რეკომენდებული) ან .apk-ისთვის და შეუძლია PR-ის შემოწმების ჩავარდნა, როდესაც ბრენჩის ზღვარი ირღვევა. დაამატეთ ეს თქვენს CI-ში ბილდის ნაბიჯის შემდეგ:

bash

tuist inspect bundle App.aab

გახსენით ბანდლის ინსაიტები → Android დაფარდაზე, რათა ნახოთ ტენდენცია და დააკონფიგურიროთ ზღვრები.

პრევიუები#

Play Console-ის შიდა ტესტის ტრეკი ყოველ გაზიარებაზე ამატებს გადახედვისა და გავრცელების დაყოვნებას. raw .apk-ის Slack-ით ან ელფოსტით გაგზავნა უფრო სწრაფია, მაგრამ კარგავს იმის თვალყურის დევნას, თუ რომელ ბილდს ეხება კონკრეტული შეტყობინება.

პლაგინს შეუძლია პირდაპირ ააწყოს და გამოაქვეყნოს აპლიკაციის ვარიანტი, ცალკე CLI ატვირთვის გარეშე:

bash

./gradlew :app:tuistShareDebug --track nightly

tuistShare<Variant> ამოცანის მოთხოვნა ანიჭებს იმ გამოძახებას გამოქვეყნების უფლებას; ჩვეულებრივი ბილდები არასდროს ტვირთავენ პრევიუებს. იხილეთ Gradle პრევიუები მხარდაჭერილი APK-ების, ხელმოწერისა და ინსტალაციისთვის.

გუნდის ჩართვა#

ქეშის მოხვედრები, ინსაიტები და სტრეს-ტესტირება ყველა იზრდება პროექტთან დაკავშირებული ადამიანების რაოდენობის მიხედვით. მიიწვიეთ თქვენი გუნდის წევრები ორგანიზაციაში დაფარდის ანგარიშის პარამეტრებიდან და დააყენეთ ერთჯერადი შესვლა (Google, Okta, Microsoft), რათა დარეგისტრირება იყოს ერთი დაწკაპუნება და არა თითოეული პირისთვის tuist auth login.

CI-ისთვის არ გამოიყენოთ პირადი შესვლა. გაიარეთ ავტორიზაცია თქვენი CI პროვაიდერის OIDC იდენტობით, ან შექმენით ანგარიშის ტოკენი დაფარდაზე CI პრესეტით და დააყენეთ ის როგორც TUIST_TOKEN. იხილეთ Gradle პლაგინის ავტორიზაცია.

პლაგინის სრული ცნობარი#

აქ მოცემული ყველაფერი არის მინიმუმი, რათა მიიღოთ სარგებელი Tuist-ისგან Gradle-ის პროექტზე. tuist გაფართოების ბლოკის, stressNewTests რეჟიმისა და CI ავტორიზაციის კონფიგურაციის პარამეტრები მოცემულია Gradle პლაგინის ინსტალაცია ცნობარში.