Как будто вашу задачу проще сделать, например, написав свой gradle плагин, где пройтись поиском по файлам проекта (учесть, что класс может лежать в jar каком-нибудь, короче заморочек с ходу много). Линтом даже без упомянутой проблемы как будто нормально не сделать, да и анализировать весь проект, даже если без библиотек, очень накладно будет.
Я не очень глубоко погружался, свои хотелки в проекте получилось решить более простыми путями, но насколько копал, после каждого модуля триггерится afterCheckEachProject, а вот checkPartialsResults один раз при формировании финального отчёта. В любом случае, первоисточник этого механизма можно попробовать поискать в UnusedResourceDetector. А я правильно понял, вы хотите подсвечивать линтом, что при использовании рефлексии класса с таким именем/пакетом не существует?
Если правильно понял, для этой задачи подходит механизм PartialResults, он как раз позволяет кешировать промежуточный результат и собирать его по всем модулям, а затем выводить в финальном отчёте. Поиск неиспользуемых ресурсов в студии работает по такому же принципу.
гитхуки это довольно неудобная в реализации штука, никак не завязанная на интерфейс. Как уже говорилось, нет цели блочить коммит, цель добавить в уже работающие предупреждения студии ещё одно. Да и кто сейчас работает на какой-то IDE, отличной от Android Studio?
В конце статьи приведены точки роста, и они явно не относятся к процессам. Статья призвана показать как делаются плагины, а не продать тот, что в итоге получился. Да и никто не начинает с места в rocket science.
В больших компаниях триггерить ci на новую сборку ПРа из-за мелкого фикса, которого можно было избежать, довольно ощутимо по ресурсам и времени. Поэтому статический анализ и спелчек часто уносят на локальные машины.
Как будто вашу задачу проще сделать, например, написав свой gradle плагин, где пройтись поиском по файлам проекта (учесть, что класс может лежать в jar каком-нибудь, короче заморочек с ходу много). Линтом даже без упомянутой проблемы как будто нормально не сделать, да и анализировать весь проект, даже если без библиотек, очень накладно будет.
Я не очень глубоко погружался, свои хотелки в проекте получилось решить более простыми путями, но насколько копал, после каждого модуля триггерится afterCheckEachProject, а вот checkPartialsResults один раз при формировании финального отчёта. В любом случае, первоисточник этого механизма можно попробовать поискать в UnusedResourceDetector. А я правильно понял, вы хотите подсвечивать линтом, что при использовании рефлексии класса с таким именем/пакетом не существует?
Если правильно понял, для этой задачи подходит механизм PartialResults, он как раз позволяет кешировать промежуточный результат и собирать его по всем модулям, а затем выводить в финальном отчёте. Поиск неиспользуемых ресурсов в студии работает по такому же принципу.
Да, странный контракт, мы пока по прежнему пользуемся методами report у context с сигнатурами без Incident, там сложнее ошибиться.
гитхуки это довольно неудобная в реализации штука, никак не завязанная на интерфейс. Как уже говорилось, нет цели блочить коммит, цель добавить в уже работающие предупреждения студии ещё одно. Да и кто сейчас работает на какой-то IDE, отличной от Android Studio?
Так коммит не блокируется, выводится алерт, точно также, как он выводится по дефолту при нажатой галочке Analyze в ui диалога коммита в студии.
В конце статьи приведены точки роста, и они явно не относятся к процессам. Статья призвана показать как делаются плагины, а не продать тот, что в итоге получился. Да и никто не начинает с места в rocket science.
В больших компаниях триггерить ci на новую сборку ПРа из-за мелкого фикса, которого можно было избежать, довольно ощутимо по ресурсам и времени. Поэтому статический анализ и спелчек часто уносят на локальные машины.