Процесс (workflow) разработки диагностики

1. Зайти в раздел issues и выбрать себе задачу из списка. Стоит выбирать задачи, еще не имеющие исполнителя, т.е. Assignees не указан (блок располагается справа, почти под заголовком).
2. Если задачи для диагностики нет, то стоит ее создать, нажав кнопку New issue
3. Написать в комментарии к задаче мейнтейнерам, что хочешь взять задачу в работу. После того как в задаче в блоке Assignees появится твой ник, можно приступать.
4. Необходимо сделать форк репозитория в GitHub, склонировать репозиторий на локальную машину и создать новую ветку-фичу (разработка ведется по git flow).
5. Если форк уже был создан, то необходимо обновить ветку develop из основного репозитория. Проще всего это делается следующим образом
   1. У локального репозитория указывается два адреса удаленных репозиториев: твой и основной
   2. Получаешь обновление с обоих репозиториев git fetch --progress "--all" --prune
   3. В локальном репозитории переключаешься на ветку develop
   4. Сбрасываешь состояние ветки до состояния основного репозитория (git reset --hard)
   5. Отправляешь ветку в свой удаленный репозиторий

6. Для создания нужных файлов в нужных местах, необходимо выполнить команду gradlew newDiagnostic --key="KeyDiagnostic", вместо KeyDiagnostic необходимо указать ключ своей диагностики. Подробная информация в справке gradlew -q help --task newDiagnostic. Параметры на момент написания этой статьи:

7. --key - Ключ диагностики

8. --nameRu - Название диагностики на русском языке
9. --nameEn - Название диагностики на английском языке

При старте будет выведен список доступных тегов диагностик. Необходимо ввести через разделитель пробел от одного до трех тегов из предложенных.

1. Выполнить разработку

2. После завершения разработки диагностики необходимо проверить изменения, выполнив тестирование, а также выполнить ряд служебных задач.
   Для упрощения создана специальная команда, запускаемая gradlew precommit из командной строки либо запустить precommit из панели задач Gradle в IDE. Состав команды на данный момент

3. check - проверка и тестирование всего проекта

4. licenseFormat - установка блока лицензии в исходных java файлах

5. updateJsonSchema - обновление json схемы

6. Если все сделано правильно, необходимо зафиксировать изменения и отправить в свой удаленный репозиторий.

7. Необходимо создать Pull request из своей фиче-ветки в ветку develop основного репозитория и заполнить информацию в описании.
8. До закрытия pull request, мейнтейнеры проведут проверку кода, выскажут замечания. Исправление замечаний необходимо производить в той же фиче-ветке, github автоматом подтянет изменения к созданному pull request.
9. Закрытие pull request подтверждает факт завершения задачи.