Системы автоматизации задач сборки?

Question

[Pavel K]

Криво обозначил тему, как это правильнее назвать?

Суть в том, что после непосредственно сборки бинарников проекта (C++, CMake) нужно
создать deb, rpm пакеты, скопировать в них бинарники, документацию, что-то куда-то переместить и т.д. и т.п.

Всё это сейчас через bash скрипты, кроме того, для каждой ОС свои нюансы в параметрах командах могут быть (отчего для каждой ОС свой скрипт с побольше части повторяющимися командами) и лишь после этого можно сказать, что проект "собран" (что бы в дальнейшем Jenkins забрал готовые артефакты).

Меня как-то слишком корёжить начало от зоопарка всех скриптов сборки под разные ОС с разным поведением и т.д. т.е. однозначно нужна кроссплатформенность и какая-нибудь однозначность синтаксиса (да, пусть меньше возможностей по сравнению со скриптами).
Может быть просто устал, но подскажите, что есть, как лучше (кроме тех же скриптов, но на Питоне и т.д.)?

Comments

[Василий Банников]

Ну раз уже есть женкинс, то почему бы на нём всё не сделать? Для разных ОС всё равно нужен будет свой скрипт для пакетирования, но компилировать можно будет 1 раз, а упаковывать и публиковать в разные репозитории - параллельно

[Pavel K]

Василий Банников, Jenkins на отдельном ПК и, к тому же, там по сути такой же скрипт из bash комманд получается.

[Василий Банников]

Pavel K, а от них ты не уйдёшь.

Вот например у нас проект есть на Rust, и нам нужно собирать rpm и deb пакеты, в качестве ci используем гитлаб.

Для каждого вида пакетов - свой набор всяких манифестов и post install скриптов (создать папки, накинуть нужные права итд).
По сути в них написано одно и то же, но разным синтаксисом.

А потом в пацплайне отдельные джобы для:
1. Сборки приложения
2. Сборки пакетов (переносятся артефакты из сборки)
3. Публикации в репозтиториях.

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

Единственное что упрощается по сравнению с плюсами и cmake - не нужно руками никакие утилиты для сборки вызывать/писать баш скрипты, всё запускается через cargo

Answer 1

[Евгений Шатунов]

Это очень хорошо что тебя корежить начало от зоопарка скриптов.

Систем управления задачами довольно много. Они есть на разных языках. Те же MSBuild, cmake, Gradle, Phing, Ant, Zig и.т.д. являются подмножеством множества систем управления задачами. Поэтому нередко люди берут тотже cmake для решения описанных у тебя в вопросе задач. cmake под все из перечисленных у тебя задач не подходит, но люди обычно плачут, колются и продолжают сидеть на кактусе.

Между тем, есть целый класс конкретно систем управления задачами. Такие системы предоставляют только инструменты менеджмента, но не дают никакого начального набора задач, в отличие от того же cmake/Gradle/...
К таким системам менеджмента задач сразу и легко можно отнести Doit, Schedule и их аналоги.

Я работаю с Doit уже больше 10 лет, периодически помогаю его развивать и всячески содействую его разработке.
Для меня Doit стал решением всех описанных у тебя задач и является решением огромного числа неописанных у тебя задач автоматизации и сопровождения процесса разработки проектов.
Doit работает быстро, эффективно, умеет пропускать задачи по условиям инкрементальности, имеет очень гибкую систему настройки поведения и, что главное, от начала и до конца весь написан на Python - одном единственном языке. Он легко интегрируется в Jenkins и позволяет полностью автоматизировать подавляющую часть задач поддержки разработки. Эта система управления задачами является самой гибкой и успешно приспосабливается к самым разным задачам автоматизации ручного труда.

Только не надо пытаться пробовать заменить абсолютно всё на что-то одно. Первое правило кроссплатформенной разработки: Под каждую платформу сборка должна быть максимально нативной. Это значит что трансляция кода и подготовка целевого артефакта сборки должны выполняться нативными для целевой платформы методами. А система управления задачами должна только запускать трансляцию, как рядовую задачу.