Результат прикрепите ссылкой на ваши GitHub-проекты в личном кабинете студента на сайте netology.ru.
Важно: ознакомьтесь со ссылками на главной странице репозитория с домашними заданиями.
Если у вас что-то не получилось, оформите Issue. Шаблон для оформления.
Не делайте ДЗ всех занятий в одном репозитории. Потом будет сложно подключать системы Continuous Integration.
- Создайте на вашем компьютере Gradle-проект.
- Инициализируйте в нём пустой Git-репозиторий.
- Добавьте в него готовый файл .gitignore.
- Добавьте в этот же каталог остальные необходимые файлы.
- Сделайте коммиты.
- Создайте публичный репозиторий на GitHub и свяжите свой локальный репозиторий с удалённым.
- Сделайте пуш и удостоверьтесь, что ваш код появился на GitHub.
- Прикрепите проект ссылкой на сайте netology.ru.
- Выполните все задания, чтобы получить зачёт.
Вам нужно взять функцию расчёта комиссии при переводе и написать для неё автотесты:
Подключите JUnit4 и JaCoCo. Добейтесь того, чтобы покрытие кода по branch было не менее 80 %:
Информацию, что значит по branch, вы найдёте на официальном сайте JaCoCo.
Итог: у вас должен быть репозиторий на GitHub, в котором будет ваш Gradle-проект. Автотесты также должны храниться в репозитории.
Если возникают проблемы с генерацией отчёта, смотрите соответствующий раздел.
Если тесты не запускаются (выдается ошибка "Test events were not received") или происходят непонятные проблемы с jacoco, удалите из build.gradle следующие строки:
test {
useJUnitPlatform()
}
Они подключают JUnit5, который конфликтует с JUnit4.
Работая в команде, вы будете запускать тесты не на своём компьютере, а при каждом пуше в облаке. Так будет видно, кто сломал сборку, а кто прислал нерабочий PR (Pull-Request). В этом вся прелесть командной работы 😈.
Мы настроим CI на базе GitHub Actions, уже встроенной в GitHub-системы.
После того как вы сделали задачу №1, перейдите в ваш репозиторий на вкладку GitHub Actions:
GitHub Actions предложит вам один или несколько Workflow по умолчанию, но лучше выбрать «Setup a workflow yourself»:
В открывшемся окне делаем по шагам:
- Меняем имя файла на
gradle.yml. - Меняем весь код на тот что ниже.
- Нажимаем «Start Commit».
- Нажимаем «Commit new file».
Код для gradle.yml скопируйте и замените целиком. Не переписывайте вручную:
name: Kotlin CI with Gradle
on:
push:
branches: '*'
pull_request:
branches: '*'
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set up JDK 1.8
uses: actions/setup-java@v1
with:
java-version: 1.8
- name: Grant execute permission for gradlew
run: chmod +x gradlew
- name: Build with Gradle
run: ./gradlew build --info
«Everything as code» и «Configuration as code» — большинство современных CI-систем следуют этому подходу, когда все необходимые настройки хранятся в текстовом файле в самом репозитории. В случае GitHub Actions в вашем репозитории создастся файл ./github/workflows/gradle.yml, поэтому не забудьте сделать git pull, чтобы он попал и в ваш локальный репозиторий.
Если вы скопируете конфигурацию неправильно, GitHub Actions сообщит вам об этом. Вот пример, в котором мы удалили у первого слова первую букву:
После того как вы закоммитите корректный файл конфигурации, на вкладке GitHub Actions можно посмотреть прогресс выполнения:
Через какое-то время получим общий итог. PASS — зелёный флажок или FAIL — красный крестик:
Для каждого коммита, для которого производилась сборка, на всех страницах GitHub будет отображаться статус. Иконки статуса кликабельны:
Можно провалиться внутрь, чтобы посмотреть логи сборки:
И раскрыть интересующий нас раздел:
Если мы уроним сборку, то это тоже будет видно:
Полностью настроенный CI на основе примеров с лекции вы можете найти по адресу: https://github.com/netology-code/ktci.
Подключить к вашему репозиторию GitHub Actions, следуя инструкции выше.
Чтобы удостовериться, что CI работает, добавьте (как мы в примере) коммит, ломающий сборку: выставьте в тестах неправильное ожидаемое значение. Убедитесь, что после Push вам покажут эту проблему.
Важно: вам не нужно каждый раз создавать заново файл конфигурации GitHub Actions. Достаточно добавлять его в новый репозиторий так же, как вы это делаете с .gitignore.
Итог:
- У вас должен быть репозиторий на GitHub, в котором расположен ваш Gradle-проект.
- К репозиторию должен быть подключён GitHub Actions.
- В истории должен быть хотя бы один коммит, ломающий сборку.
В случае, если тесты проходят, но при запуске команды gradle test jacocoTestReport получается похожая картина:
Убедитесь, что используется JDK версии 14 или ниже. Для этого идём в File -> Project Structure
На вкладке Project проверяем версию. Меняем в случае необходимости:
Если JaCoCo отказывается работать даже в этом случае, следует изменить ваш gradle.yml на следующий вариант:
name: Kotlin CI with Gradle
on:
push:
branches: [ master, main ]
pull_request:
branches: [ master, main ]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Set up JDK 1.8
uses: actions/setup-java@v1
with:
java-version: 1.8
- name: Grant execute permission for gradlew
run: chmod +x gradlew
- name: Build with Gradle
run: ./gradlew test jacocoTestReport
- name: Upload Build Artifact
uses: actions/upload-artifact@v2
with:
name: jacoco_reports
path: build/reports/jacoco/test/html
В таком случае JaCoCo-отчёт будет сгенерирован на каждый пуш в ветку master/main. Или на каждый пуш в ветку, на которую открыт PR в master/main. И загружен на Github в виде артефакта для скачивания.
Скачать и посмотреть отчёт можно следующим образом:
-
Нажимаем на статус сборки, переходим в детали.
-
Дожидаемся успешной сборки, если статус жёлтый. Далее скачиваем полученный архив.
-
Далее распаковываем архив, смотрим результаты в index.html.