Преамбула Некоторое время назад, решив навести порядок в нашем коде, мы выбрали Чекстиль .
Думаю проект знакомый и не нуждается в представлении.
До этого команда использовала общий репозиторий, где хранились стили кода и настройки намерений для идеи.
Добавляя в проект чекстиль, мы в первую очередь преследовали цель получить возможность превратить ошибки в оформлении стиля кода в ошибки сборки.
Легким движением руки чекстайл подключался к корневому пому проекта, разработчики ознакомились с нововведением, а сборки на Teamcity научились проверять чекстайл перед коммитом.
Но вот незадача: в наших рядах появился вредитель.
Как мы с ним боролись — под катом.
Вредоносное изменение было замечено сразу во время сборки следующего релиза.
Сборка аварийно завершилась с сообщением:
Да, подумал я, сейчас я тебя разберу.[ERROR] Habr.java[31:1] (imports) IllegalImport: Import from illegal package - org.apache.commons.lang [ERROR] Habr.java[32:1] (imports) IllegalImport: Import from illegal package - org.apache.commons.lang
И я взял на себя вину.
Личность злоумышленника была быстро установлена.
Каково же было мое удивление, когда выяснилось, что злоумышленником был я.
Но я собрал проект перед коммитом, запустил checkstyle. 
Естественно, это была оплошность из разряда «все проверил, добавлю сюда одну строчку, она точно ничего не сломает».
Код поправлен, релиз пересобран, ситуация решена.
Однако на следующий день ситуация повторилась с моим коллегой.
В Intelij Idea есть отличная опция «Переформатировать код», которую можно включить в диалоговом окне фиксации.
Рекомендую всем своим коллегам, намереваясь забыть об этой проблеме раз и навсегда, но вот опять - сборка не собирается, в логе: [ERROR] Habr.java[136:27] (whitespace) WhitespaceAround: 'if' is not followed by whitespace.
Конечно, кто-то забыл включить эту опцию, кто-то проигнорировал это письмо.
Но вернемся к началу разговора — мы собирались использовать checkstyle для переноса ошибок проектирования кода на этап сборки — но не обязательно переносить их на этап сборки патча.
Teamcity+gerrit в помощь
Наша компания использует его уже несколько лет. Геррит провести код-ревью проекта.Почему бы не совместить проверку кода с checkstyle. Вооружившись Гуглом и желанием решить проблему кривых стилей раз и навсегда, я приступил к настройке этой фермы.
Опущу неудачный опыт и опишу вариант интеграции, который работает и сегодня.
В своей работе мы будем использовать Плагин публикации статуса фиксации , тимсити, геррит. Сам плагин включен в Teamcity начиная с версии 7.1 (если я ничего не путаю).
Настройка запуска checkstyle
Прежде всего мы создаем план сборки, в котором одним из шагов мы должны выполнить checkstyle.
Разница между checkstyle:check и checkstyle:checkstyle в том, что первый в случае нарушений провалит сборку, второй соберет весь проект и сформирует отчет обо всех нарушениях.
Оптимальный способ — запустить checkstyle:checkstyle в качестве первого шага и chekstyle:check в качестве второго, что приведет к сбою сборки.
Добавить издателя статуса фиксации
Затем в сборку добавляется издатель со статусом фиксации с помощью функции «Добавить сборку».
Настройки тривиальные — указываем адрес геррит-сервера, git корень, из которого собирается сборка, и логин, под которым будем взламывать геррит. Аутентификация в gerrit основана на открытом ключе, поэтому мы генерируем пару ключей на сервере Teamcity и агентах и регистрируем ее в gerrit.
Обеспечиваем начало сборки
Остается только настроить сборку таким образом, чтобы при появлении нового коммита в обзоре сборка запускалась автоматически.Для этого в разделе «Триггеры сборки» добавьте новый триггер удаленного запуска ветки.
Мы настраиваем его в ветке refs/changes/*.
Убеждаем Teamcity, что мы — это мы
Ну и самое главное.Teamcity, используя триггер удаленного запуска Branch, запускает персональные сборки.
Это означает, что для запуска сборки Teamcity должен признать своего пользователя автором коммита.
Чтобы понять, узнал вас Teamcity или нет, можно навести курсор на любой из ваших коммитов в истории сборки.
Если вы видите текст Пользователь TeamCity: неизвестный, это означает, что потребуется другая настройка.
В этом же диалоге есть строка Имя пользователя VCS: - скопируйте ее содержимое и перейдите в профиль пользователя Teamcity. В разделе «Настройки имени пользователя контроля версий» запишите скопированное значение «По умолчанию для всех корней VCS:».
Публикуем отчеты
Еще один элемент — необязательный — вы можете настроить в сборке Teamcity функцию под названием «Обработка XML-отчетов», чтобы Teamcity анализировал логи проверок стилей и показывал нарушения стиля в результатах сборки.Пример настроек ниже.
После этих настроек можно попробовать отправить код Герриту на проверку.
В течение некоторого времени должна запуститься сборка, которая по результатам поставит +1 или -1 в геррит. Если время прошло, а сборка не началась, ищите причину в журнале teamcity. Используя описанный мной метод, вы также можете контролировать выполнение модульных тестов для каждого коммита.
Теги: #java #ci #gerrit #java #git
-
Оптимизация Gamethread В Unreal Engine 4 Ч.2
19 Oct, 24 -
Яндекс.диск Синхронизирует Локальные Папки
19 Oct, 24
