Куча мелких пйлов так влиять не должна

смотри на утилизацию ресурсов сервера, проверь сеть между клиентоми гитлабом - iperf например. Последний раз когда я такое словил была проблема с 10g dac-кабелем между гипервизором и свичем бггг именно на том хосте где жил гитлаб.
То что ты ссылку дал вообще не показатель - там опять же сеть между облачным гитлабом и неведомым сервером у тех кто ишью завел и полный ноль инфы. Может у них дженкинс в ДО, а там сеть колбасит стабильно несколько раз в неделю по всем регионам

+

начать можно с простого действия - берешь и качаешь вгетом на сервак с гитлабом файл гиговый отсюда например https://speed.hetzner.de/  если видишь те же 50 кб\c можешь сразу считать что проблема явно не в гитлабе, если качается нормально,  но вдруг проблема в обратке то дальше iperf. Само собой стоит вообще все логи посмотреть, dmesg и т.д. - ну абсолютно дефолтные действия при поиске проблем. В гитлабе реально тормозить нечему(именно в разрезе работы с git), в раннерах тоже(если не считать конечно вариант с репкой на несколько гб да еще и с  бинарниками)

Привет, вот сейчас задам вопрос который всегда хотел задать, но не знал как сформулировать.

На досуге решил поиграться с новыми фишками гитлаба, настроил офигенный пайплайн с автоматическим деплоем в kubernetes, динамическими окружениями и review apps и всем таким.

Работает - круто, но непонятно как быть с форками проекта, так как в случае форка описанный .giltab-ci.yml инициализирует пайплайн для форка, при этом отваливается по таймауту, так как форк не имеет ни настроенных variables ни запущенных runner'ов.

Соответсвенно при мердж реквесте, отображается статус этого пайплана для форка а не для основного проекта, который буквально говорит что "всё плохо".

Вопросов в итоге два:
- Как избежать инициализации .gitlab-ci.yml для форков? - то есть испольнять его только в контексте основного проекта и игнорировать во всех остальных.
- Как исполнять пайплайн для присланных мердж реквестов в контексте основного проекта, а не в контексте форка?

👍 спасибо

Может быть, only: merge_requests, branch:master плможеь?

Тогда они будут исполняться только после мерджа в мастер, а нужно чтобы исполнялось при создании MR, для того чтобы review apps с динамическими окружениями отрабатывали

костыли подклаывать придется, в концепции гитлаб флоу форк вообще самостоятельная и самодостаточная сущность походу.
частично может поможет
only:
 variables:
    гитлабсиай_енабле == 1

надо посмотреть кстати как у них сделано для самого гитлаба

Возможно добавить условие, что CI_MERGE_REQUEST_SOURCE_PROJECT_ID не совпадает c CI_MERGE_REQUEST_PROJECT_ID

Естественно, на практике я не пробовал 😅

выглядит как план,  правда надо проверять при том что сами заявлены как альфа, плюс пачка оговорок в доке

Добрый день, возможно будет оффтопом, но мне здесь лампово интересоваться:
Jfrog container registry > GitLab container registry ?

во во. тоже вопрос про жфрог артифактори. так ли оно хорошо? стоит своих денег?

Привет как использовать переменные CI / CD в yml файле ?

например парольь