Comments 12
Статья крутая. Сами думаем в этом направлении
Замечания
- wget http://ftp.ru.debian.org/debian/pool/main/j/jq/jq_1.4-2.1+deb8u1_amd64.deb
Не делайте так. Где гарантия, что файл не подменят по дороге? Или то что его вообще не уберут? Еще такая инструкция дает моргающие пайплайны, если будут хоть сколь-нибудь значительные сбои по сети (например, мы сидим за корп прокси и он тупо не успевает проверять весь трафик) Хорошая идея — собрать базовый докер со всеми необходимыми компонентами и использовать его в пайплайне.
Более существенно — я не понял, можно ли бейджи показывать не на статус проекта, а на статус конкретного коммита. Ведь действительно качество кода в одной ветке может нас и не особо интересовать, если у нас разработка в несколько веток идет. Или нас вообще интересует как меняется качество кода конкретного коммита в зависимости от развития сонаркуба (поменялся набор правил — и уже старый "хороший" код стал "плохим")
/dev/./urandom
— почему именно так, а не /dev/urandom
?
Более существенно — я не понял, можно ли бейджи показывать не на статус проекта, а на статус конкретного коммита.
Конкретного — скорее нет, чем да. Последнего — да. Так же есть бейджи, показывающие изменения с последнего коммита.
Ведь действительно качество кода в одной ветке может нас и не особо интересовать, если у нас разработка в несколько веток идет.
Для этого надо использовать SonarQube Developer Edition.
нас вообще интересует как меняется качество кода конкретного коммита в зависимости от развития сонаркуба (поменялся набор правил — и уже старый «хороший» код стал «плохим»)
Финальная оценка конечно поменяется. Чем жестче правила проверки, тем ниже будет оценка.
Мы тоже использовали раньше для Java проекта. На сколько помню там не очень хорошо работал Code Coverage в Spring Boot приложении. Интегрешн тесты не считались покрытием. Team City встроенным тулом обрабатывал без проблем. Вы с таким не сталкивались?
8 сонар может это из коробки, а для версий постарше есть плагины, вот для гитлаба
P.S.
Посмотрите CodeClimate, тоже много метрик отдает. Например может GitLab отдавать информацию как эволюционирует код
Правильно ли я понимаю (тут не особо силен), что гит комментарии не изменяют исходный хэш-сумму коммита? И получается, что являются таким вот особым способом хранить мета-информацию в самом репозитории? Каким-то образом можно проверифицировать, что гит-комментарий не был несанкционированно изменен (например, гит коммит можно заверить gpg подписью)
Посмотрите CodeClimate, тоже много метрик отдает. Например может GitLab отдавать информацию как эволюционирует код
я так понял, что это только для облачного гитлаба ?
Я имел в виду этот механизм
Отображение разработчикам статуса контроля качества исходного кода в SonarQube