Pull to refresh

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 ?

UFO just landed and posted this here

И что? Кто мешает заменить MitM'ом пакет jq, скажем, на пакет с докером. Или чем ещё похлеще с валидной gpg подписью
Я уж не говорю о том, что как будто, кажется, что dpkg -i вообще никакой проверки аутентичности пакета не производит

Если ставить через apt, то проблем не будет точно.
Более существенно — я не понял, можно ли бейджи показывать не на статус проекта, а на статус конкретного коммита.

Конкретного — скорее нет, чем да. Последнего — да. Так же есть бейджи, показывающие изменения с последнего коммита.
Ведь действительно качество кода в одной ветке может нас и не особо интересовать, если у нас разработка в несколько веток идет.

Для этого надо использовать SonarQube Developer Edition.
нас вообще интересует как меняется качество кода конкретного коммита в зависимости от развития сонаркуба (поменялся набор правил — и уже старый «хороший» код стал «плохим»)

Финальная оценка конечно поменяется. Чем жестче правила проверки, тем ниже будет оценка.
Хороший вопрос подняли Anthrax_Beta и gecube. Даже сам факт этого диалога показывает, что утилиты и сервисы типа SonarQube это всего лишь инструменты. А правильное их применение — вопрос организационный, и во многом зависящий от уровня зрелости процессов в компании.

Мы тоже использовали раньше для Java проекта. На сколько помню там не очень хорошо работал Code Coverage в Spring Boot приложении. Интегрешн тесты не считались покрытием. Team City встроенным тулом обрабатывал без проблем. Вы с таким не сталкивались?

Если я правильно помню, то SonarQube берет параметр CodeCoverage на основе данных плагина jacoco
Есть еще 3 способ, рендерить отчет сонара прямо в систему управления исходным кодом.
8 сонар может это из коробки, а для версий постарше есть плагины, вот для гитлаба

P.S.
Посмотрите CodeClimate, тоже много метрик отдает. Например может GitLab отдавать информацию как эволюционирует код

Правильно ли я понимаю (тут не особо силен), что гит комментарии не изменяют исходный хэш-сумму коммита? И получается, что являются таким вот особым способом хранить мета-информацию в самом репозитории? Каким-то образом можно проверифицировать, что гит-комментарий не был несанкционированно изменен (например, гит коммит можно заверить gpg подписью)


Посмотрите CodeClimate, тоже много метрик отдает. Например может GitLab отдавать информацию как эволюционирует код

я так понял, что это только для облачного гитлаба ?

Если я правильно понял, то, комментарии, которые Вы пишите в системе управления кодом, (тоже делает и Сонар в Вашем Гитлабе) это не commit message. Они хранятся в БД гитлаба и на комит не влияют
Sign up to leave a comment.

Articles