>> Давно уже в Community Edition, то есть бесплатно.
> а гитлабовцы пишут, что премиум

А, эти зеркала. Пардон. Я подумал, что речь про registry mirror. Да, эти -- пока только в премиуме. Но у меня для этого shell-скрипт есть. Наваял буквально за час, там ведь надо по сути всего-ничего: git clone --mirror / git push --mirror. Само собой, что покупать ради этого премиум -- нонсенс.

>> Создайте в проекте безопасников токен с минимальным набором нужных привилегий и триггерите пайплайн этого проекта через него.
> курлом что ли? тогда между пайплайнами нет связи и, если пайплайн безопасников выполнился не успешно, то пайплайн разработчиков об этом никак не узнает. Я нашел только открытые тикеты на эту тему

Держи: https://gitlab.com/almaops/gitlab-trigger-deploy
Я этот скрипт написал лет пять назад, когда впервые столкнулся с данным вопросом.
Используем для деплоев в основном, но по сути он триггерит пайплайн другого проекта, дожидается его завершения и наследует его статус. Спецом для делплоев обернул полгода назад в контейнер, ибо это применение триггера -- самое частое.

>> Но в конечном итоге её ж пофиксили.
> мы уже извернулись через отправку почты и чаты. Криво, но три года ждать не могли.

А мы -- через allure и pages. Старый проверенный надёжный инструмент.

>> В любом случае mask -- это не 100% защита, и это надо понимать.
> да это понятно, учитывая, в т.ч. и доступ к .gitlab-ci.

Доступ в .gitlab-ci.yml тут не при чём, ибо что тебе толку от возможности его поправить, если пароль от волта с реквизитами прода доступен только в protected-бранче.

> Но к примеру тот же дженкинс не позволяет просматривать или редактировать секреты после сохранения, генерирует +/- случайные пути к файлам и т.д.

Ну, при наличии доступа к скрипту пайплайна -- это что в дженкинсе, что в гитлабе обходится на раз-два. Тут не о чем спорить. Суть в том, что маскировка переменных -- не более чем защита на случай, если сам ошибёшься где-то. Для защиты секретов нужен protected-бранч с ответственным мейнтейнером во-первых, во-вторых vault как второй уровень защиты, и в-третьих строго прописанные регламенты гитфлоу, в которых зафиксирована ответственность мейнтейнера в случае компрометирующих секреты правок в пайплайн.

> Просто в случае gitea знаешь на что подписался: она идет бесплатно и нужное приходится доделывать самому. А тут вроде деньги заплатил, а нужное приходится доделывать самому :)

Понимаю, но у меня с gitlab ровно та же песня: подавляющее большинство инсталляций -- именно community edition. А нужный платный функционал реализован своими скриптами. Большинству клиентов это как раз очень нравится: то, что можно обойтись бесплатной версией гитлаба, но за счёт нашей экспертизы использовать его на полную мощность. Я ничего не имею против gitea, однако gitlab допиливать нужно кратно меньше: а подавляющему большинству и вовсе хватает бесплатной версии "как она есть".