Доступна открытая система автоматизации сборочных процессов Сicada, позволяющая на своём сервере развернуть инфраструктуру, похожую на GitHub Actions, Azure DevOps и Gitlab CI, не зависящую от облачных сервисов. Код проекта написан на языке Python и распространяется под лицензией AGPLv3...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=60068
Сливает пароли только в правильные места.
Выглядит неплохо. Надеюсь не будет странных ограничений с магическими числами как у гитлаба, типа "кэшей не может быть больше четырех, а хэш можно вычислять только от одного или от двух файлов, но не от трех, хаха"
хм, опять копируют удачное проприетарное решение, а потом будуть ныть "а почему у нас форматы несовместимые" ?Надеюсь они добавят хороших фич, чтобы отличаться от конкурентов.
Пользоваться чужими услугами всегда дороже, чем делать самому. Так что возможность поднять свой CI/CD это уже плюс.
хм... ну не знаю
Это надо или держать нужного человека в штате или брать "админа на час".
Плюс разовая закупка билд серверов.
Мне кажется, что в некоторых случаях выбрать "чужие услуги" может быть выгоднее.
Ну, то есть без админа (и вообще людей, худо-бедно понимающих в IT, чтобы набросать последовательность команд для сборки) такие проекты нормально живут, проблемы начинаются только на стадии автоматизации сборки?
Может свои серверы покупать и всё такое. Интересно, могут ли автоматизированные сборки жить на других компьютерах, например на компьютерах программистов (в отдельном окружении, например)
Странное решение, чтобы сэкономить на серверах.
Проще уж Gitlab свой поднять. Там все по умолчанию есть.
Да, но GitLab какой-то уж больно тормозной по сравнению с Gogs/Gitea/Forgejo, а в этих нет CI/CD...
> удачное
> Github Actions
Еще один CI с собственным синтаксисом?
Ай, маладцы!
Мало нам GH Action, Gitlab CI, Drone/Woodpecker и еще десятка разных
Будет еще одинОни издеваются?
И так приходится в голове держать все вышеперечисленные, потому что у одних клиентов одно, у других другое, у третьих третье, а у четвертых вообще черт в ступе и на роботе-пылесосе
Старая добрая "Война стандартов".
> Старая добрая "Война стандартов".Угу
При чем больше всего бесят CI которые используют таки yaml, но каждый свой(как раз вот GH Actions, Gitlab CI, Drone, вроде и Jenkins)
Вроде все похожи, но у каждых своя какая-то особенность
И такой думаешь "Ага! Я уже это делал для вон того клиента!", а потом понимаешь, что делал под один, а у этого другой и надо адаптировать, хоть все и похоже, сидишь и переделываешь
причем тут yaml?
Ну как это причём. Написал же человек: путается в синтаксисах разных CI-систем, потому ему yaml-ы сродни китайцам -- все на одно лицо.
Можете попробовать внедрять Dagger CI
Есть Jenkins
Остальное от лукавого
Bash скрипты покрывают практически все потребности CI/CD, простой тому пример VoidLinux, где вся система сборки это по сути "фреймворк" на bash.Вся декларативщина только вредна. Люди совсем перестают думать и считают что оно должно работать в любых ситуациях, а это совсем не так. Через ENV файл или переменные окружения можно передать любые данные, условный ENV файл с секретами может генерировать перед запуском сама CI/CD система, я такой подход практически нигде не видел из "облачных решений", все упариваются с переменными окружения, а затем затирают Credentials в логах, казалось бы есть подход проще.
Например, данных подход `cache node_modules using hashOf("package-lock.json")` к кешированию вызовет проблемы как только смузихлебы из NPM решат поменять логику хранения модулей и или еще чего сломают, исправить вы это не сможете пока сервис не реализует изменения под видом `cache_v2`.
Единственное что сервис должен предоставить свои, безопасные для процесса сборки и логгирования, варианты консольных утилит деплоя результата сборки и кеширования нужных каталогов - это я за, но никто не заморачивается. Например, в гитхабе/лабе за это отвечает код со стороны сервера исполняя декларативный файл сборки, а это не очень то безопасно.
>Bash скрипты покрывают практически все потребности CI/CD, простой тому пример VoidLinux, где вся система сборки это по сути "фреймворк" на bash.Ну уже не смешно даже. Баш это прекрасный выбор, если а) всё займёт не больше нескольких десятков строк и логика не очень сложная б) вы точно знаете где смузихлёбы в) ничего кроме баша вы не видели.
Вне этих трёх случаев баш по меркам 2023 года это ДНИЩЕ, от которого нужно держаться подальше: отсутствие типов; смешанные в кучу управление процессами, шаблонизатор строк и control statements; убогий синтаксис; несколько видов экспаншенов; десятки всяхих set +puk; set -srenk, меняющих поведение; в 2023 году из коробки нет банального логирования. И "фреймворк" на баше такой же получится, никто кроме автора не станет его развивать.
Какое еще логирование? Все что требуется от CI это запустить последовательно команды системы сборки с правильными ключами и затем тесты если они есть и по факту все. Логи пишет система сборки, а не декларативная вундервафля вендорлока. Еще заяви что нет всеми "любимого" if err исключений и абстракций с интерфейсами, йопт этого там быть не должно. Нужно вызвать сложную логику в системе сборки - это должно быть реализовано на уровне системы сборки, есть python, есть nim, но йопт не средствами самого CI это железобетонный VENDOR LOCK.Вы изобрели 4 колёсных велосипед с педалями и тычите в других что у их велосипеда всего 2 колеса. CI выполняет команды сборки, но никак не переизобретает систему сборки с нуля. Если в каком-то NPM с этим проблемы пусть решают это на уровне Node.JS окружения, а не CI.
>Все что требуется от CI это запустить последовательно команды системы сборки с правильными ключами и затем тесты если они есть и по факту все.Ну это не CI, а действительно скриптик в три строки. Однажды понадобятся триггеры, история и воспроизведение сборок, доступы разграничить и т.д. и т.п. — вот и придётся изобретать CI вместо баш-скрипта. Там и логирование понадобится, и много чего ещё.
> Еще заяви что нет всеми "любимого" if err исключений <...>, йопт этого там быть не должно.Вообще-то должно и есть. Оно называется trap.
> Баш это прекрасный выбор, если а) всё займёт не больше нескольких десятков строк и логика не очень сложнаяВ наше время у любого языка есть собственный сборочный тулкит, и безусловно, его и надо использовать. Но все действия по подготовке окружения, к сборке, деплою, итд итп -- можно и нужно писать на баше (либо ином шелле, если умеете).
У шелла в целом две области применения. Первая -- это обёртки. Вторая -- организация параллельного выполнения процессов. И с обеими задачами он справляется отлично.
> Вне этих трёх случаев баш по меркам 2023 года это ДНИЩЕ, от которого нужно держаться подальше: <...>
Ну вот и держитесь, коли он вас так на эмоции пробивает.
Я же вот точно знаю, где смузихлёбы, и хотел бы напомнить вам, что вы недостаточно знаете объект вашей критики, чтобы иметь о нём какое бы то ни было мнение, и уж тем более, чтобы транслировать его на публику.
Вы в очередной раз всё перепутали.
Ну, удачи на собеседовании - рогам-и-копытам будет очень интересно узнать про voidlinux и ci\cd на bash'е - правда денег за это они не заплатят, но скорее всего послушают. Всем остальным - очень не очень, даже слушать не будут.
В компании, предоставляющей shared hosting на основе LAMP, могут заинтересоваться.
Сейчас уже не 90-е, и такие компании сложно найти, но они пока остались.
> В компании, предоставляющей shared hosting на основе LAMP, могут заинтересоваться.
> Сейчас уже не 90-е, и такие компании сложно найти, но они пока
> остались.Неее... им же это адище ПОДДЕРЖИВАТЬ потом - может даже после ухода Васяна в мэшин-лёрнинг-дейта-сайенс или еще какую модную хуцпу. Проще уж какую "панельку"(ТМ) прикрутить\фэтэпэ открыть, а Васяны с voidlinux'ами пусть на стороне рогов-и-копыт кон-тин-ни-ёс ди-ли-ви-ри реализуют.
> Ну, удачи на собеседовании - рогам-и-копытам будет очень интересно узнать про voidlinux
> и ci\cd на bash'е - правда денег за это они не
> заплатят, но скорее всего послушают. Всем остальным - очень не очень,
> даже слушать не будут.Правильно нужно обязательно всеми конечностями наступить в помет вендор лока чтобы тебя железобетонно со смузихлебной вакансии не уволили. 👍
>> Ну, удачи на собеседовании - рогам-и-копытам будет очень интересно узнать про voidlinux
>> и ci\cd на bash'е - правда денег за это они не
>> заплатят, но скорее всего послушают. Всем остальным - очень не очень,
>> даже слушать не будут.
> Правильно нужно обязательно всеми конечностями наступить в помет вендор лока чтобы тебя
> железобетонно со смузихлебной вакансии не уволили. 👍Борис! Борись!
> Bash скрипты покрывают практически все потребности CI/CDВот кстати согласен. Проблема shell-скриптов в том, что это тьюринг-полный язык, и для большинства современных айтишников его освоение сопряжено с определёнными трудностями. Но если им дать шаблоны, по которым надо писать код -- кое-как справляются. Ревью, естественно, обязателен.
> Через ENV файл или переменные окружения можно передать любые данные, условный ENV файл с секретами может генерировать перед запуском сама CI/CD система, я такой подход практически нигде не видел из "облачных решений"
Мы поступаем просто: в IaC-репозитории храним шифрованные файлы с кодом. Через unix env var в пайплайн передаётся только ключ для расшифровки. Однако, строго говоря, расшифровка файла с секретами -- это уже не задача системы CI/CD. Её задача -- передать переменную и дёрнуть скрипт(ы).
> Но если им дать шаблоны, по которым надо писать кода есть такие готовые ? чтобы нулевым пунктом было "не используейте башизмы".
для С есть что-то на букву "М" и с акцентом на безопастный код.
>> Но если им дать шаблоны, по которым надо писать код
> а есть такие готовые ? чтобы нулевым пунктом было "не используейте башизмы".У нас есть референсный код, который мы даём новым сотрудникам. Не в публичном доступе. Если хочешь, могу выслать. Напиши мне на мыло.
Загона по поводу пункта "не используйте башизмы" кстати не имеем. У нас позиция несколько иная: писать скрипты под определённую версию шелла и таскать её с собой.
> для С есть что-то на букву "М" и с акцентом на безопастный код.
для shell я рассчитываю по крайней мере, что человек прочитает ABS
Для сборки hello world-ов сойдет если оно было бесплатное.
>Отличительной чертой Сicada является предоставление для определение логики работы предметно ориентированного функционального языка программирования, поддерживающего переменные, выражения, циклы, условные блоки и встроенные функции.Если есть repl и синтаксис пайпалайнов из шелла, шелл можно будет выкинуть на помойку.
Но, похоже, шелл они там сделали ключевым словом, так что расходимся и потихоньку пилим новый шелл без нюансов с пробелами. Как только смогут такой написать, ну или вбухают в обычный шелл код как данные и правила, все эти докерфайлы, экшоны и тому подобное пойдёт на выброс.
> python = ">=3.11" . Модные ребятки.
> реализованный подход также решает проблему с несовместимостью YAML-форматов конфигурации, используемых в разных платформах автоматизации сборок. В Сicada предлагаются независимые от платформ универсальные типы событийОдиннадцатый конкурирующий стандарт?