Самое простое - использовать докер. Во встроенном регистри гитлаба есть ретеншен и его вроде как можно настроить на х последних образов

Сложнее, когда нужна не-докер-центричная разработка - тогда только остаётся опрашивать гитлаб апи и подчищать уже неактуальные артефакты. Касательно примеров - лучше спросить @Agumilev или поискать на гитхабе ) явно кто-то что- о такое реализовывал, но там не сложно, можно и самому по доке сообразить

Либо есть ещё варик - отгружать артефакты во внешне хранилище - начиная от с3 (там есть версии и ограничение по колву) или в нечто типа jfrog artifactory

У меня статика, не докер а просто выгрузка в s3 bucket

А в чем проблема хранить все артефакты за последние полгода?

Или много места сжирает?

Ну и вообще если на то пошло, всегда можно откатиться на рабочий коммит и запустить пайплайн для него

Ну статика немного, бэк 90м занимает каждый образ. Я вот думаю как оптимизировать статикк. Может действительно хранить все полгода

В с3 нет политики по количеству, только по времени. В свое время городил для этого лямбду

Спасибо за уточнение.

Доброго времени суток.
Есть определенное кол-во приватных репозиториев (ansible-роли), в каждом из них добавлен один и тот же публичный ключ как deploy key, в CD приложений лежит плейбука, которая выгружает их с помощью зашифрованного с помощью ваулта приватного ключа.
Проблема следующего характера, данный флоу я реализовывал год назад, и сейчас понадобилось добавить еще один репозиторий (роль), и теперь же при попытке добавления этого публичного ключа я получаю - Fingerprint has already been taken, Deploy keys projects deploy key fingerprint has already been taken, Gitlab что-то поменял? Как раньше я смог добавить его в штук шесть репозиториев?
p.s. пустые строки в конце ключа убирал

всем привет, просьба помочь допилить код:  необходимо чтобы возможность запускать папйлан вручную и автоматом при создании MR, отдельно работало для релизных веток

в таком виде не работает и получаем такую хрень

Привет. А можно ли сформировать полный .gitlab-ci.yml если есть множество include'ов?

вопрос в том, что иногда не очень удобно дебажить, когда стейджи разбросаны на множество реп и добавлены через include (велосипед не мой)

CI Lint выдает ошибку, но чтобы вкурить детали, приходиться 5 реп пересматривать. Может есть какой-то инструмент показать все в одном месте что парситься при линте

конечно инклуды пиши себе откудам надо и все будет работать

Кто сталквивался с подобным в gitlab-ci просьба подключиться к вопросу

не пропомню что бы было, что-то готовое, налабай на python3 по быстрому

там минут 10 от силы нужно

spasibo