на лету? ))  или в смысле CI/CD? (про них плюсую)

Потому что здесь все на винле и на ноутах. Ну чо уж. Да местные плагины я поставил. Сразу. Сейчас хочу картинку. Варнингов нет

Так. В итоге вернулся к чему начал. Чем построить картинку. Одна либа помирает в странном месте. Вторая генерит puml, котлрые неисьедает plantuml.jar

🙂

если этот puml не секретный - зашли мне его?

Подскажите, каким инструментом можно сделать релизную сборку из нескольких проектов на гитлабе? То есть нужно собрать (по команде и/или при мерже в мастер или при выпуске релиза на гитлабе... ) сбилдить бэк, фронт, подложить миграции, все это заархивировать и зашифровать в один файлик и как-то где-то выложить чтобы можно было смотреть историю релизов в возможностью скачивания как заархивированного-шифрованного файла обновления. так и по отдельности билдов фронта, бэка, миграций этого релиза ? Использует ли кто-то для этого Капистрано? https://12factor.net/ru/build-release-run

bash / python скрипт в каком нибудь Jenkins'е

гитлаб ci для такого слишком куц

ну наверное, я не нашел в гитлабе ничего что могло быть на это похоже... мне кажется это логичным)) В принципе можно самописно все сделать, тем более что большая часть написана уже в этом самом архиваторе-шифровальщике. Я сейчас это ручками делаю, осталось морду накрутить и бд для истории сделать

хотя обычно всё таки разделяют по разным инструментам
сборка артефактов - gitlab ci или аналоги
деплой - ansible или аналоги
а чем запускать деплой, уже каждый выбирает себе тулзу по вкусу

Сначала устаналиваешь расшиериние Go. Потом Ctrl+Shift+P -> там пишешь goinstall и в дропдауне нажимаешь Go:Install/Update Tools. Релоад и готово.

в смысле куц? ))
запустить тот же bash скрипт/make он в состоянии ))

это всё равно всё делается "руками" (скриптами)
а чем ты их будешь запускать - дело твоё: берёшь любой CI-сервер

у gitlab ci всё привязано к репозиторию, что создаёт головную боль для проектов, которые живут во множестве реп

.gitlab-ci файлик в корне репы это конечно удобно на первых порах, но с ростом проекта это вызывает больше боли, чем удобства

смотря какая цель стоит:
собрать все последние версии указанных проектов
или определённую сборку фиксированных версий этих проектов...

+ multiproject pipelines
https://docs.gitlab.com/ee/ci/multi_project_pipelines.html

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

Это не значит, что оно всем не подходит

мета-проект?

мета-проект это какое-то устоявшееся понятие? продукт кодится в двух проектах , фронт и бэк.