Информация о некритичных проблемах выявленных в рамках CI/CD

В комбайнах типа GitHub/GitLab можно оставлять из CI/CD комментарии к pull request/merge request.

Текстовый файл читать никто не станет. Это проверенно многократным опытом. Почту, скорее всего, тоже.

Я делал так, что пайплайн помирал. И тот же линтер запихивал в прекомит хуки на локальную машину разраба. Прежде чем пушнуть, пущай проверяют что всё как полагается.

Почему-то многие разработчики истово ненавидят прекоммит хуки. Аж до бешенства, истерики устраивают, когда предлагаешь внедрить.

Ну это уже организационные вопросы. У нас это обязаловка. А если разраб всё равно норовит вылить ерунду, то это даже не попадёт на стенд.

делал так, что пайплайн помирал
пущай
как полагается

Похоже на подход мудака, который сам не программирует, да и не смог бы.

Тема не о том, надо ли линтер вызвать локально или как развалить пайплайн по экзиткоду.

автоматом вываливать ишью на разраба, запушившего последний коммит, с максимальным приоритетом.

подход мудака, который сам не программирует, да и не смог бы.

Ну, во-первых, попрошу без оскорблений. Во-вторых, я просто привык делать всё нормально. А если нормально не получается, то лучше вообще не делать. В-третьих, можно отсылать результат пайплайна в слак | тг | ещё куда. Как минимум, если речь идёт о гитлабе, можно настроить результаты пайплайнов в отдельный канал в слаке. Но сейчас же вскроется, что разработчики и слак не хотят читать и вообще надо им в жопу дуть и чай с кофе носить.

Так что да, может вопрос и не о том, разваливать ли пайплайн, но метод я назвал достаточно эффективный. В конце концов никто не отменял опцию --no-verify, если так уж надо обойти хук.

я просто привык делать всё нормально

Нет оснований полагать, что ты вообще знаешь как делать нормально что-либо, особенно в сфере, в которой ты не разбираешься (программирование).

Но сейчас же вскроется, что разработчики и слак не хотят читать и вообще надо им в жопу дуть

Конечно, ведь никаких слаков, телеграмов и прочего дерьма в разработке точно быть не должно. Это вещи совершенно ненужные и совершенно вредные. Смею предположить, что в сисадминстве и девопсинге использование слаков и телег аналогично ненужно и вредно.

Никто не мешает ронять пайплайн с линтером никак не затрагивая пайплайн с деплоем. Но вообще что это за такие нарекания, которые хочется чтобы чинились, но при этом чинить их не обязательно. Либо трусы, либо крестик, то есть либо выкиньте свой линтер вообще, либо мужественно поправьте текущие нарекания, и роняйте все пайплайны при появлении новых.

Ещё, если линтер работает приемлемое время, можно запускать его на сервере в момент push и откланять push если линтер не сработал. Это также не будет мешать деплою.

но при этом чинить их не обязательно. Либо трусы, либо крестик, то есть либо выкиньте свой линтер вообще, либо мужественно поправьте текущие нарекания, и роняйте все пайплайны при появлении новых.

Отчасти согласен с вами. В идеальном случае так и должно быть. Оно или достойно починки, или недостойно внимания вообще. Дескать определитесь.

Никто не мешает ронять пайплайн с линтером никак не затрагивая пайплайн с деплоем

Сейчас у меня примерно так и сделано. Деплой отделен, но линтер живет вместе тестами.

Может быть его отделить просто и пусть это всё будет «красное». Либо просто удалить из CI, оставить разработчикам на запуск по собственной инициативе.

Спасибо вам за доводы.

Нет оснований полагать, что ты вообще знаешь как делать нормально что-либо, особенно в сфере, в которой ты не разбираешься (программирование).

На чём основывается эта информация?

Конечно, ведь никаких слаков, телеграмов и прочего дерьма в разработке точно быть не должно.

Да хоть почтовым голубем высылайте, мне какое дело. При таком уровне обсуждения нет никакого желания вообще помогать.

для GitLab https://docs.gitlab.com/ee/ci/yaml/#allow_failure

Сколько раз эту страницу приходилось открывать, но allow_failure не замечал. Интересно.

В этом же CI, есть скрипт - что-то вроде линтера. Если он не вышел с exit code 0 и пустым stderr, это не идеально, но не должно останавливать пайплайн.

исправлять недочеты до тех пор, пока или линтер не перестанет мигать, или из кода не уберется фигня

многие разработчики истово ненавидят прекоммит хуки

это чисто человеческая тема. Надо общаться, выяснять почему человек против. Они же не идиоты, просто у них другая картина мира и они не понимают, почему им же станет лучше от хороших хуков

они не понимают, почему им же станет лучше от хороших хуков

и завершающего апперкота.

и завершающего апперкота.

это если не согласятся с хуками

Что-то я подумал, даже в команде из одного меня это идеальное решение. Если смотреть на тесты отдельно — это нервы: вскрылась какая-то там ошибка, надо идти накидывать новый коммит. Запустить тесты локально можно и забыть, ведь бывает так, что правки вроде как мелкие и не должны ничего сломать, но фиг там. Слаки/почта/телега — максимально неудобно.

Потому, собственно, так и сделали. Причём не знаю что тут товарищ возникал, это решение принималось всей командой. Получилось недурно. Чтобы всё работало на любой машине, запихали это в докер. Перед коммитом запускается контейнер с тестами, а если он выходит нормально, то всё работает как надо.