Comments 13
Думал кто-то сделал тулзу, которая сама берет .gitlab-ci.yml и выполняет все шаги…
эх раньше было время, локально гитлаб раннер установил и можно дебажить джобы, но почему то вырезали этот функционал
На днях нашел тулзу которая эмулирует работу gitlab runner
https://github.com/firecow/gitlab-ci-local
Есть некоторые недостатки, но в общем работает
Но как вы это сделаете для продакшена, когда 90% токенов наследуются и надёргать из репо, авторизоваться в реджистри и прочая машинерия типа записи в бакет – просто недоступны? Потому что кибербезы не допустят слива токенов. Поднимать "всё своё"? Vault, argocd и далее по списку нужных стейджей? Давайте обсудим)
Ну лучше уж тогда описать кучу сервисов в compose.yml, и дергать их черех docker compose run --rm , удобнее же
Хм. Показаны примеры не очень реалистичных CI/CD. У меня это как правило более ветвистые скрипты с if и ТД. Как написал человек выше, в ci легко могут быть переменные из интерфейса и/или внешние сервисы с ограниченным доступом.
Как будто не очень рабочий вариант для 90% случаев (если не больше).
У нас было два десятка docker-образов, 75 переменных, пять внешних API с ограниченным доступом, пол-солонки секретных токенов и целое множество условных конструкций if/else всех видов и расцветок, расставленных по наитию. А ещё пачка раннеров с тегами, и ручные триггеры. Не то чтобы это был необходимый запас для локальной отладки. Но если начал собирать пайплайн, становится трудно остановиться.
Как проверять CI-джобы локально с помощью Docker