Проект Gradle

plaintext

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

Следуйте этому пути, чтобы подключить существующий проект Gradle к Tuist. Плагин Gradle dev.tuist связывает локальный кэш сборок 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 добавляет задержку на проверку и распространение при каждом обмене. Отправка сырого .apk через Slack или электронную почту быстрее, но теряется связь с тем, к какой сборке относится конкретное сообщение.

Плагин может собрать и опубликовать вариант приложения напрямую, без отдельной загрузки через CLI:

bash

./gradlew :app:tuistShareDebug --track nightly

Запрос задачи tuistShare<Variant> включает эту операцию в публикацию; обычные сборки никогда не загружают превью. См. Превью для Gradle для информации о поддерживаемых APK, подписи и установке.

Подключите команду#

Попадания в кэш, аналитика и стресс-тестирование становятся эффективнее с увеличением количества людей, подключённых к проекту. Пригласите коллег в организацию через настройки аккаунта в дашборде и настройте Единый вход (Google, Okta, Microsoft), чтобы онбординг занимал один клик, а не требовал индивидуального tuist auth login для каждого.

Для CI не используйте личный логин. Аутентифицируйтесь через OIDC-идентичность вашего провайдера CI или создайте токен аккаунта с пресетом CI в дашборде и установите его как TUIST_TOKEN. См. Аутентификация плагина Gradle.

Полная справка по плагину#

Всё описанное здесь — это минимум, необходимый для получения пользы от Tuist в проекте Gradle. Параметры конфигурации для блока расширения tuist, режима stressNewTests и аутентификации CI находятся в справке Установка плагина Gradle.