Comments 11
И потом андроид программист должен поправить вручную этот текст и ... что потом? Написать письмо iOS разработчикам чтобы они тоже поправили? Или кому? Почему орфография вдруг стала проблемой разработчиков только одной платформы и только на этапе комитта? Мне кажется тут фундаментальная ошибка в процессах, а плагин тут только для того чтобы научиться писать плагины.
В плане воркфлоу по-моему лучше добавлять такое на ci/cd как проверку пул реквестов. Коммит должно быть сделать легко, а при необходимости можно делать фиксапы и аменды. Иначе это отвлекает от собственно того, что ты хочешь сделать в момент коммита.
В больших компаниях триггерить ci на новую сборку ПРа из-за мелкого фикса, которого можно было избежать, довольно ощутимо по ресурсам и времени. Поэтому статический анализ и спелчек часто уносят на локальные машины.
Кволити гейты на PR не я придумал. Когда у тебя в любом случае перед мержем должны пройти тесты, не вижу проблемы добавить туда еще спелчекер как аддон к линтеру раз переживаете, что опечатки попадут в финальную сборку. В остальном диагностики это здорово. Я сам очень люблю когда IDE мне подсказывает как улучшить код. Просто блокировать возможность сделать коммит не нужно
Спасибо за статью, узнал пару новых фишек для себя.
Из того, что могу подсветить по контенту статьи:
Зря вы взяли скриншот IDEA из моей старой статьи, сейчас интерфейс IDEA выглядит иначе) Чтобы инициализровать новый проект с плагином, можно не только создавать его из IDEA, но и воспользоваться готовым шаблоном-репозиторием от JetBrains, так можно получить самую актуальную конфигурацию подобных проектов. Новая версия gradle-intellij-plugin (он теперь называется intellij-platform-gradle-plugin) позволяет удобнее настраивать новые проекты. А ещё, это сразу настроит CI/CD план на github actions (правда, вы используете Gitlab, но настроить сборку артефактов можно и там).
Где-то в описании статьи похоже забыли отметить, что для завязки на git-операции, нужно будет добавить зависимость на git-плагин внутри IDEA.
Ради интереса: почему не стали пользоваться удобным DSL для описания UI? Там как раз вторая версия вышла.
Поддержу других комментаторов: прикольно, что вы интегрировали проверку орфографии в IDE, но чтобы проблему пофиксить "надёжнее", стоило продублировать её ещё и на CI/CD. Да, дополнительное время на стат. анализ, однако нельзя будет просто так взять и смёрджить с ошибками.
P.S. Очень рад, что мои статьи и доклады по плагинам (например, самая первая статья или воркшоп) находят отклик и вдохновляют людей писать свои собственные статьи про разработку плагинов. Но всё же, когда материалы из них используются (например, скриншоты), хочется видеть упоминание авторства. Давайте исправим это? 😊
Такой вопрос: а в чем преимущество этого метода перед гит-хуками? Кажется, что можно аналогичное реализовать на них, чтобы работало вне зависимости от выбранной IDE?
гитхуки это довольно неудобная в реализации штука, никак не завязанная на интерфейс. Как уже говорилось, нет цели блочить коммит, цель добавить в уже работающие предупреждения студии ещё одно. Да и кто сейчас работает на какой-то IDE, отличной от Android Studio?
В статье явно описала про гитхуки, что через них тоже можно реализовать проверки. Плагин для студии необходим для удобства и простоты разработки под андроид, большинство разработчиков пользуются коммитом через студию
Разработка плагина для Android Studio