Потому что гитлаб и дженкинс - это разные инструменты для разных задач. Дженкинс вообще, например, не про хранение кода и коллаборативную работу с ним - все равно какое-то хранилище тащить...
есть :-) Если это докер контейнеры. Берешь и запускаешь локально. Потом собираешь в кучу. Все как обычно. А в gitlab даже есть возможность нажать debug и попасть в интерактивный терминал внутри джоба пайплайна. Но обычно это отключено из security соображений....
я специалист по гитлабу - он реально очень поднялся за последнее время. Но, как я указал ниже, есть конвергенция - те же защищенные переменные и ветки и CODEOWNERS есть и в ГИТХАБЕ...
это меня вообще убило... В частности, про Hadolint. Явно статья - неудачный перевод неудачного материала. Из перевода как будто раздел про Linux-хосты с docker, а по изначальному смыслу как будто речь про Linux ВНУТРИ docker... хотя даже там эта мысль очень неудачно сформулирована...
Итоговый результат простой - теперь ко мне будут приходить новички-коллеги и внедрять вот эти вот "вредные" советы, которые статья рекомендует.
Насчет шизофрении - есть же механизмы разграничения прав на уровне кода самого репо. Тот же CODEOWNERS, protected в гитлабе. Но мое мнение, что эти механизмы не очень надежны и их всегда можно поскипать (даже если есть жесткий аудит кода - разрабы могут проглядеть вредоносные изменения)....
И при прочих равных самое железобетонное - это отдельное репо на каждую потенциальную проблему... Да, кстати, мне ролевой модели гитлаба тоже не хватает (там всего пять ролей, кажется, и нельзя сделать высокую степень гранулярность типа разраб А может коммитить только в ветку А, но не Б... и только определенное подмножество файлов... точнее можно, но там такое количество костылей, что сразу хочется застрелиться)
вынужден согласиться :-) Я именно поэтому и практикую отдельные репо для деплоя (в крайнем случае, их всегда можно пнуть из gitlab-ci как дочерний пайплайн с нужными переменными) и отдельными репами для инфры...
ну, по сути это и есть маппинг. Его можно через IaC реализовать /и через тот же ансибл прокатать поверх гитлаба, чтобы сделать связи между нужными репами/ :-) либо через механизм вызова пайплайна из пайплайна в самом гитлабе.
собираются коммит месаджи с прошлого билда
логика гитлаба немного другая - он не пытается коммит мессаджи между билдами собирать, а триггерит сборку на каждый пуш или мерж... Хотя можно по-всякому настроить.
ну, что значит в Дженкинсе работает? Дженкинс же не настолько умный, чтобы понимать из каких библиотек состоит Ваш проект. Или нет?
А насчет "вотчит" - ну, е-мае, есть же два подхода - polling и pushing. Сам Дженкинс умеет только в поллинг репы, что фигня, потому что создает избыточную нагрузку на хранилище репов. С другой стороны, хранилище репов типа гитлаба всегда имеет исходящий вебхук, который дергается при паше в репо. И у Дженкинса есть входящий вебхук.. Так что можно и такую модель с Пушем изменений реализовать...
Хороший кейс. Но точно так же можно вынести сборку в отдельную репу в гитлабе (принцип гитлаба - если что-то не получается - создавай новое репо на каждый чих )))). И получить по сути тот же Дженкинс в обличие гитлаба.
Касательно зависимостей. Нет - про такое не слышал. Но если Вы можете каким-то образом агрегировать эти проекты (через api дернуть как-то их список или они сами регистрируются в какой-то системе), то проблемы дернуть ИХ пайплайны вообще никакой нет. Т.е. все равно маппинг "репозиторий библиотеки -> репозитории проектов" надо где-то прикапывать...
build system needs to be made entirely deterministic
это влажные фантазии :-) Хотя было бы очень здорово, если б это было так. Почему я в это не верю? Потому что Вы пишете о том, что по сути сборки должны быть детерминированы на уровне инструкций (ну, мы это еще хоть как-то обеспечим), но еще и бинарно одинаковы в конечном счете (а здесь есть большая проблема - мы движемся в этом направлении, но цель еще не достигнута). Я уж не говорю о том, что даже параметры железки, на которой идет сборка, могут быть важны.
Second, the set of tools used to perform the build and more generally the build environment should either be recorded or pre-defined
опять же в идеальном мире.
Вы ничего другое тоже не можете пачкой в нескольких репозиториях. Или подстройте под это процессы или реогранизуйте репозитории.
здравое замечание. Но в случае инклюда темплейтов я потенциально могу гарантировать их обратную совместимость. Хотя поддерживать это та еще морока будет. Проще уж версии пайплайна сборки версионировать. А здесь и получается необходимость строить маппинги от репы к версии пайплайна. Красиво не получается. Насчет реорганизации - согласен. Меня больше всего тошнит от половинчатых решений. И сейчас индустрия вроде пришла к двум кардинально разным подходам - либо Монорепо (и своя нормальная система сборки), либо куча микрорепозиториев (грубо - одна репа - один артефакт). В последнем случае то же плюс минус понятно что делать, но такое ощущение, что тот же гитлаб навязывает именно эту парадигму. Правда, разработчики могут начать путаться в нескольких репах, как в трех соснах )
Если что - я не претендую на истину в последней инстанции ) У меня скорее есть инженеры, которые могут CI/CD сделать, а я так - ковыряюсь потихоньку :-) Сам хочу какой-то вменяемый подход, чтоб не изобретать его заново, но все что я вижу - выглядит как фу-фу-фу
Очень верное замечание, но тогда нам придётся мириться с тем, что
Мы не можем пачкой обновить пайплайн в нескольких репозиториях (а это бывает нужно)
У нас пайплайн не всегда будет Зеленый, просто по причине того, что он сам поломался. И если, например, мы запускаем старый пайплайн, то окружение уже другое и он не выполнится. И придётся вносить корректирующие коммиты, после чего о reproducible builds можно забыть
И? Это хорошо/плохо? Удобно/неудобно?
Потому что гитлаб и дженкинс - это разные инструменты для разных задач. Дженкинс вообще, например, не про хранение кода и коллаборативную работу с ним - все равно какое-то хранилище тащить...
еще один повод мигрировать на гитлаб )))
есть :-) Если это докер контейнеры. Берешь и запускаешь локально. Потом собираешь в кучу. Все как обычно. А в gitlab даже есть возможность нажать debug и попасть в интерактивный терминал внутри джоба пайплайна. Но обычно это отключено из security соображений....
сколько уровней абстракции нам нужно, чтобы вкрутить лампочку, вызвать пиццу...???
я специалист по гитлабу - он реально очень поднялся за последнее время. Но, как я указал ниже, есть конвергенция - те же защищенные переменные и ветки и CODEOWNERS есть и в ГИТХАБЕ...
согласен ужасные советы в статье, ужасные доводы.
это меня вообще убило... В частности, про Hadolint. Явно статья - неудачный перевод неудачного материала. Из перевода как будто раздел про Linux-хосты с docker, а по изначальному смыслу как будто речь про Linux ВНУТРИ docker... хотя даже там эта мысль очень неудачно сформулирована...
Итоговый результат простой - теперь ко мне будут приходить новички-коллеги и внедрять вот эти вот "вредные" советы, которые статья рекомендует.
Насчет шизофрении - есть же механизмы разграничения прав на уровне кода самого репо. Тот же CODEOWNERS, protected в гитлабе. Но мое мнение, что эти механизмы не очень надежны и их всегда можно поскипать (даже если есть жесткий аудит кода - разрабы могут проглядеть вредоносные изменения)....
И при прочих равных самое железобетонное - это отдельное репо на каждую потенциальную проблему... Да, кстати, мне ролевой модели гитлаба тоже не хватает (там всего пять ролей, кажется, и нельзя сделать высокую степень гранулярность типа разраб А может коммитить только в ветку А, но не Б... и только определенное подмножество файлов... точнее можно, но там такое количество костылей, что сразу хочется застрелиться)
вынужден согласиться :-) Я именно поэтому и практикую отдельные репо для деплоя (в крайнем случае, их всегда можно пнуть из gitlab-ci как дочерний пайплайн с нужными переменными) и отдельными репами для инфры...
не полиморфный ))) а скорее просто способ автоматизации настройки N+1 репозиториев в гитлабе
ну, по сути это и есть маппинг. Его можно через IaC реализовать /и через тот же ансибл прокатать поверх гитлаба, чтобы сделать связи между нужными репами/ :-) либо через механизм вызова пайплайна из пайплайна в самом гитлабе.
логика гитлаба немного другая - он не пытается коммит мессаджи между билдами собирать, а триггерит сборку на каждый пуш или мерж... Хотя можно по-всякому настроить.
ну, что значит в Дженкинсе работает? Дженкинс же не настолько умный, чтобы понимать из каких библиотек состоит Ваш проект. Или нет?
А насчет "вотчит" - ну, е-мае, есть же два подхода - polling и pushing. Сам Дженкинс умеет только в поллинг репы, что фигня, потому что создает избыточную нагрузку на хранилище репов. С другой стороны, хранилище репов типа гитлаба всегда имеет исходящий вебхук, который дергается при паше в репо. И у Дженкинса есть входящий вебхук.. Так что можно и такую модель с Пушем изменений реализовать...
Хороший кейс. Но точно так же можно вынести сборку в отдельную репу в гитлабе (принцип гитлаба - если что-то не получается - создавай новое репо на каждый чих )))). И получить по сути тот же Дженкинс в обличие гитлаба.
Касательно зависимостей. Нет - про такое не слышал. Но если Вы можете каким-то образом агрегировать эти проекты (через api дернуть как-то их список или они сами регистрируются в какой-то системе), то проблемы дернуть ИХ пайплайны вообще никакой нет. Т.е. все равно маппинг "репозиторий библиотеки -> репозитории проектов" надо где-то прикапывать...
это влажные фантазии :-) Хотя было бы очень здорово, если б это было так. Почему я в это не верю? Потому что Вы пишете о том, что по сути сборки должны быть детерминированы на уровне инструкций (ну, мы это еще хоть как-то обеспечим), но еще и бинарно одинаковы в конечном счете (а здесь есть большая проблема - мы движемся в этом направлении, но цель еще не достигнута). Я уж не говорю о том, что даже параметры железки, на которой идет сборка, могут быть важны.
опять же в идеальном мире.
Вы ничего другое тоже не можете пачкой в нескольких репозиториях. Или подстройте под это процессы или реогранизуйте репозитории.
здравое замечание. Но в случае инклюда темплейтов я потенциально могу гарантировать их обратную совместимость. Хотя поддерживать это та еще морока будет. Проще уж версии пайплайна сборки версионировать. А здесь и получается необходимость строить маппинги от репы к версии пайплайна. Красиво не получается. Насчет реорганизации - согласен. Меня больше всего тошнит от половинчатых решений. И сейчас индустрия вроде пришла к двум кардинально разным подходам - либо Монорепо (и своя нормальная система сборки), либо куча микрорепозиториев (грубо - одна репа - один артефакт). В последнем случае то же плюс минус понятно что делать, но такое ощущение, что тот же гитлаб навязывает именно эту парадигму. Правда, разработчики могут начать путаться в нескольких репах, как в трех соснах )
Если что - я не претендую на истину в последней инстанции ) У меня скорее есть инженеры, которые могут CI/CD сделать, а я так - ковыряюсь потихоньку :-) Сам хочу какой-то вменяемый подход, чтоб не изобретать его заново, но все что я вижу - выглядит как фу-фу-фу
Не помню ) могли и что-то переиграть
Используйте on premise установки gitlab/github/bitbucket
Не туда смотрите. Не те экшены. Не про пайплайны ci/cd
Конвергенция продуктов во весь рост
Очень верное замечание, но тогда нам придётся мириться с тем, что
Мы не можем пачкой обновить пайплайн в нескольких репозиториях (а это бывает нужно)
У нас пайплайн не всегда будет Зеленый, просто по причине того, что он сам поломался. И если, например, мы запускаем старый пайплайн, то окружение уже другое и он не выполнится. И придётся вносить корректирующие коммиты, после чего о reproducible builds можно забыть
Мало упоминают, потому что не лучшее решение (1) и потому что платное (2) == плохо масштабируется
Реально у гитлаба убер фича, что раннеров можно подключать бесконечно
Ну, согласен. Я сам к этому пришёл. Такой же подход возможен и в гитлабе