Комментарии 55
Пробовал как замену legacy TeamCity, но показалось очень неудобным (даже по сравнению с TeamCity) и сырым. Может настоящий девопс справился бы без проблем, но я не смог без костылей типа sleep между аплоадом артефакта и его даунлоадом. Переезжаем на self hosted GitLab в итоге.
Это было открытием для меня, что в GitHub появился такой функционал, о котором мы поговорим позже
Звучит как кривой перевод с английского (если это не перевод, то кривой русский). Чтобы не быть голословным, аналоги:
- "Для меня стало открытием, что в GitHub есть такой функционал (о нем будет эта статья)"
- "Наличие такого функционала в GitHub стало для меня открытием"
У меня от actions смешанные чувства. Некоторые решения просто супер, некоторые - полный эпик фейл. Например, острая дистриминация между "нормальными" actions и написанными на javascript. Спасибо, вот мне в стек ansible/molecule/pytest только кода на JS не хватало.
Взаимодействие с несколькими репозиториями - боль и мрак. Иметь per repo token почему-то они не хотят, нужно городить 30-50 строчный код для получения github apps токена, с помощью которого получается ghs-токен, с помощью которого можно клонировать.
Внутри воркера - кривая убунта с кучей занятых портов (всякие mono и прочий хлам), и без вариантов. Софт ставится меееедленно (полторы минуты - и это от каждого запуска CI).
Отсутствие вложенных actions (нельзя сделать dispatch внутри actions) делает любой DRY крайне сомнительным.
Постоянные истории "ну это сложно" на, казалось бы, тривиальные задачи (например, запретить запуск actions из non-protected branches).
Отсутствие вложенных actions
Вроде бы у них появились composite actions.
Да, я пробовал. На практике всё очень ужасно, потому что интерфейсы в/из нужно описывать в двух местах (особенно, секреты), и экономии букв почти никакой.
А почему бы секреты не хранить отдельно, в том же волте или секрет менеджере, и загружать секреты, когда стартует приложение? Уже по-моему была тема, что codecov хакнули и загрузили репозитории Твилио.
Так тоже можно, но это приводит во-первых к неудобным процессам взаимодействия (например, одна из целей "разных секретов" в том, чтобы один и тот же код мог работать с разными окружениями - как это в hashivault сделать? только передачей ещё секретов).
В целом, управление секретами превращается в отдельную странную боль. Половина от этой боли - из предположения, что workflow хранятся в том же гите, где и код (что, на самом деле, большая ошибка - подход jenkins'а, где описание job'ы отдельно от кода, который он собирает (и даже выполняет) мне всё-таки кажется более разумным).
Так тоже можно, но это приводит во-первых к неудобным процессам взаимодействия (например, одна из целей "разных секретов" в том, чтобы один и тот же код мог работать с разными окружениями — как это в hashivault сделать? только передачей ещё секретов).
Но с "несекретными" секретами вида имя энва например гораздо проще жить и хранить их можно где угодно.
Это если вы доверяете коду всех бранчей одинаково.
Классический пример: есть репа с CI, есть код, который тестирует чужие MR на ephimerial что-то (vm, контейнеры и т.д.) Там есть секреты, но их важность определяется доступом к созданию/удалению виртуалок. А есть деплой в стейджинг/продакшен, и там секреты по возрастающей всё важнее.
Вытаскивание этих секретов в хашиволт не решает эту проблему, потому что мы хотим иметь разный уровень доверия разным веткам. Вся шизофрения в том, что мы не можем описать это доверие в коде, потому что код доступен для модификации.
У гитхаба есть "энвайременты" для разделения уровней доступа к секретам (включая ручной апрув), но это всё равно не решает проблему шизофрении, во-вторых секреты плодятся и мешаются, в третьих они это делают только для публичных реп или за большие деньги.
Насчет шизофрении - есть же механизмы разграничения прав на уровне кода самого репо. Тот же CODEOWNERS, protected в гитлабе. Но мое мнение, что эти механизмы не очень надежны и их всегда можно поскипать (даже если есть жесткий аудит кода - разрабы могут проглядеть вредоносные изменения)....
И при прочих равных самое железобетонное - это отдельное репо на каждую потенциальную проблему... Да, кстати, мне ролевой модели гитлаба тоже не хватает (там всего пять ролей, кажется, и нельзя сделать высокую степень гранулярность типа разраб А может коммитить только в ветку А, но не Б... и только определенное подмножество файлов... точнее можно, но там такое количество костылей, что сразу хочется застрелиться)
Вы уже очень активно гитлаб обсуждаете, а человек гитхабовый CI описывал. У них разные модели (со своими идиотизмами).
я специалист по гитлабу - он реально очень поднялся за последнее время. Но, как я указал ниже, есть конвергенция - те же защищенные переменные и ветки и CODEOWNERS есть и в ГИТХАБЕ...
Главное wtf гитлаба - в существовании единственного "pipeline" в единственном файле. В гитхабе этот вопрос разрулили куда изящнее, т.к. есть целый каталог с произвольным числом workflow.
Например, мне до сих пор не понятно как интегрировать в gitlab manual jobs рядом с нормальным pipeline по push'у. Пачкой if'ов? Криво.
подход jenkins'а, где описание job'ы отдельно от кода, который он собирает (и даже выполняет) мне всё-таки кажется более разумным).
Ну, согласен. Я сам к этому пришёл. Такой же подход возможен и в гитлабе
Хороший кейс. Но точно так же можно вынести сборку в отдельную репу в гитлабе (принцип гитлаба - если что-то не получается - создавай новое репо на каждый чих )))). И получить по сути тот же Дженкинс в обличие гитлаба.
Касательно зависимостей. Нет - про такое не слышал. Но если Вы можете каким-то образом агрегировать эти проекты (через api дернуть как-то их список или они сами регистрируются в какой-то системе), то проблемы дернуть ИХ пайплайны вообще никакой нет. Т.е. все равно маппинг "репозиторий библиотеки -> репозитории проектов" надо где-то прикапывать...
Т.е. все равно маппинг «репозиторий библиотеки -> репозитории проектов» надо где-то прикапывать...
Блин ну вот это совершенно криво, особенно когда у тебя десятки библиотек и десятки проектов. Исключительно дело проекта, от чего он зависит и что вотчит. И в дженкинсе это работает прекрасно, видимо на нём и останемся. До кучи он ещё и одну большую и древнюю svn репу с бинарными ресурсами у нас вотчит. PS: только у меня доступно 219 реп в местном гитлабе…
ну, что значит в Дженкинсе работает? Дженкинс же не настолько умный, чтобы понимать из каких библиотек состоит Ваш проект. Или нет?
А насчет "вотчит" - ну, е-мае, есть же два подхода - polling и pushing. Сам Дженкинс умеет только в поллинг репы, что фигня, потому что создает избыточную нагрузку на хранилище репов. С другой стороны, хранилище репов типа гитлаба всегда имеет исходящий вебхук, который дергается при паше в репо. И у Дженкинса есть входящий вебхук.. Так что можно и такую модель с Пушем изменений реализовать...
Дженкинс же не настолько умный, чтобы понимать из каких библиотек состоит Ваш проект.
Конечно нет. В проекте есть jenkins pipeline script, где указан список реп которые надо счекаутить и вотчить, и если любая из них меняется, то собирается новый билд, собираются коммит месаджи с прошлого билда в коммит месадж билда кладётся саммари (да, у нас сборки в гите лежат тоже). В другом проекте другой список зависимостий, и каждый из них лежит только в самом этом проекте.
ну, по сути это и есть маппинг. Его можно через IaC реализовать /и через тот же ансибл прокатать поверх гитлаба, чтобы сделать связи между нужными репами/ :-) либо через механизм вызова пайплайна из пайплайна в самом гитлабе.
собираются коммит месаджи с прошлого билда
логика гитлаба немного другая - он не пытается коммит мессаджи между билдами собирать, а триггерит сборку на каждый пуш или мерж... Хотя можно по-всякому настроить.
Генерация воркфлоу/пайплайна из ансибла - это ОЧЕНЬ плохая затея. Полиморфный CI - это уже где-то в районе программистского гольфа.
не полиморфный ))) а скорее просто способ автоматизации настройки N+1 репозиториев в гитлабе
Код, который генерирует код, который запускает этот самый код... Брр.
Я это реализовал (гитхаб), но 30 строк питона для танцев с токенами и отвратительное послевкусие.
подход jenkins'а, где описание job'ы отдельно от кода, который он собирает (и даже выполняет) мне всё-таки кажется более разумным
От этого ломается версионирование. Уже нельзя просто так взять и собрать билд от коммита N, потому что вам в пару к нему надо как-то найти подходящую к нему версию джобы M. Ибо нет никаких гарантий что то что из себя представляет джоба на сегодняшний день совместимо с тем что из себя представлял репозиторий год назад.
Очень верное замечание, но тогда нам придётся мириться с тем, что
Мы не можем пачкой обновить пайплайн в нескольких репозиториях (а это бывает нужно)
У нас пайплайн не всегда будет Зеленый, просто по причине того, что он сам поломался. И если, например, мы запускаем старый пайплайн, то окружение уже другое и он не выполнится. И придётся вносить корректирующие коммиты, после чего о reproducible builds можно забыть
Вы ничего другое тоже не можете пачкой в нескольких репозиториях. Или подстройте под это процессы или реогранизуйте репозитории.
Простите, если у вас другое окружение, то у вас не reproducible builds. https://reproducible-builds.org/
First, the build system needs to be made entirely deterministic: transforming a given source must always create the same result. For example, the current date and time must not be recorded and output always has to be written in the same order.
Second, the set of tools used to perform the build and more generally the build environment should either be recorded or pre-defined.
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 сделать, а я так - ковыряюсь потихоньку :-) Сам хочу какой-то вменяемый подход, чтоб не изобретать его заново, но все что я вижу - выглядит как фу-фу-фу
Мир неидеален, увы. Поэтому билд-системы пытаются от него изолироваться. Контейнеры, пайплайны-внутри-репозитория-с-проектом, фиксированное билд-окружение (в виде того же докер-образа) - это вот всё про изоляцию. Понятно что всё-равно *на каком-то уровне* проходит водораздел "вот досюда окружение зафиксировано, а дальше нет и там надежды только на обратную совместимость".
Вот тут вот всё и начинает танцевать вокруг проекций Футамуры и прочих интересных вопросов.
В принципе, нормально, что проект содержит инструкции по сборке себя. makefile хранится в репозитории с кодом, это нормально.
Не нормально, если он же хранит инструкции по своему деплою. makefile, который аплоадит пакет на pypi (npm, whatever) - это уже очень fishy. Граница между этими областями крайне любопытна (например, в районе контейнеров и их аплоада), но моя админская интуиция говорит, что если эту границу старательно поддерживать, то жизнь становится легче.
Где-то в коде описано как собрать код. Рядом описано что ему нужно для сборки (requirements и локи, может, даже, описание reproducible-среды). Это всё ещё ответственность кода.
Но вот что сделать с кодом после сборки - это уже не должно быть ответственностью репозитория с кодом. Если в myci.xml написано, что после сборки foo с версией bar==42.42.42 её нужно загрузить на foopackages, а потом оттуда пойти на сервера foos и поставить туда их, то это ничем не лучше, чем php-страничка, которая одной рукой ходит в базу по хардкоженному адресу, другой генерирует css'ку, а третьей сохраняет свои плагины, качаемые по урлу, рядом с собой. Тот же уровень смешения слоёв, порождающий боль и паталогические связи.
В этом смысле "описание деплоя в гите с приложением" - это шаг назад, к php-супу времён shared-hosting.
С гитхабом у меня не получилось, сыроват их ci/cd. Из последнего, работал с гитхабом, пайплайны получились удовлетворительными. А так, я большой фанат Octopus Deploy. Но о нем мало упоминают.
Начал работать с GitHub Actions ещё в декабре, и что я вам скажу..
Для небольших коммерческих/не коммерческих кейсов и не сложных тасок по поставке обновлений/билдов/деплоя подходит на ура, и если учесть что в месяц около 2к фришных минут на репу - вообще круто.
До сих пор успешно используется в кейсе с b2b ecommerce продуктом, ибо там всё просто:
1. Ченжи и пару операций с конфигами
2. Билд docker имаги
3. Деплой на aws ecs
Проще пареной репы, без всяких дженкинсов и т.д.
Так же для всяких мелкий проектов на реакте отлично заходит (аля активная разработка инфо-портала, который держим на s3, и нужно постоянно билдить и подливать свежую статику).
Но, не подходит для более серйозных задач, где вы уже хотите играть в сесюрити, правильный мультистейджинг докер билда и прочие плюшки :)
В статье две фактические ошибки.
Первая:
один момент я вспомнил про GitLab экшены, но для этого мне нужно было перемещать мой репозиторий с GitHub.
В гитлабе не экшены - там просто пайплайны через .gitlab-ci.yank
Вторая - перемещать ничего не нужно. Использовать гитлаб ci/cd можно и с репами битбакета и гитхаба. Но можно упереться в количество бесплатных минут в месяц на shared runners. Но и у гитхаба вроде сборки не «бесконечные», а в гитлабе проблема решается очень просто - заказом своего раннера
— В гитлабе не экшены
Вот ссылочка. Там экшены:
docs.gitlab.com/ee////////user/project/quick_actions.html
> Использовать гитлаб ci/cd можно и с репами битбакета и гитхаба.
Вроде как с репами гитхаба только в платной версии, нет?
Деплоить проект на сервак легче же, чем изучать actions. Простенький деплой на git hooks. Делаешь commit & push и приложение улетает на сервак, там ветки сольются, и systemd рестартанёт ваше приложение. Сама настройка сервака пять минут. Ну или какой-нить ансибл заюзать в связке с чем-то.
Отсылать коммерческий софт(исходники) дяде, по мне не гуд.
Отсылать коммерческий софт(исходники) дяде, по мне не гуд.
Используйте on premise установки gitlab/github/bitbucket
Как я познавал ci/cd, Гитхаб экшены