Если я правильн опонимаю вопрос. То вероятно использовать внешнее хранилище. Redis например: Ветка -> tag Но я не знаю зачем такое надо

Каждый мерж порождает запуск пайплайна, билдом исходников, сбором артефактов, билдом имаджа контейнера ну и затем с тестами и тп

Вопрос - дальше как с этим тегом оперировать, после слияния веток коммит другой, $BUILD_ID другой, ничего общего к чему бы можно было зацепиться, кроме как где-то хранить отдельно

После слияния веток хеш коммита не меняется. Если вы мерджите со сквошем или ещё откуда берётся мердж коммит - откуда уверенность что артефакт из этой ветки выйдет такой же как в той что замерджили?

После слияния веток хеш коммита не меняется. Если вы мерджите со сквошем или ещё откуда берётся мердж коммит - откуда уверенность что артефакт из этой ветки выйдет такой же как в той что замерджили?

меняется на хеш мёрж-коммита

Тогда артефакт который сбилдится в source ветке будет несоответствать коду в destination ветке

я так понимаю это как-то по разному в разных ci? ибо в gitlab у меня коммиты для мерджа складываются в один реквест. brainfck (

в гитлабе вообще сборка идет по бранчу)

фу скип сиай

поставь точку перед название жобы)

https://docs.gitlab.com/ee/ci/yaml/#hidden-keys-jobs

squash commits только для элитки, и в целом бажная вещь)

ребят, нужна помощь\совет, чот в отчаянии. Кто собирает образы в Gitlab(другие CI возможно также ведут себя). Как в одной ветке ссылаться на артефакт\образ из другой, чтобы не пересобирать образ для каждой ветки? Прям велосипедить начинаю, явно не туда иду

Поэтому имхо это идея плохая и я бы даже сказал вредная - юзать артефакт который билдился для другой ветки

ребят, нужна помощь\совет, чот в отчаянии. Кто собирает образы в Gitlab(другие CI возможно также ведут себя). Как в одной ветке ссылаться на артефакт\образ из другой, чтобы не пересобирать образ для каждой ветки? Прям велосипедить начинаю, явно не туда иду

не поделитесь примером как "надо"? Всё же так все и делают - собирают и гоняют одинаковые тесты на каждой ветке?

Коллеги подскажите пожалуйста как заставить Service принудительно рвать коннект с клиентом. Например если pod на который смотрит service упал поднялся другой pod с другим ip. А клиент об этом ни чего не знает. Что бы заставить клиента переконектится надо разорвать соединение. А оно висит пока не закончится timeout

в самом первом жобе пайплайна собираешь

мы гоняем все тесты на каждой ветке в гитлабе. маленькие сервисы, маленькие репозитории, быстрые тесты. вот и профит

видимо и мне туда дорога, но это же не то совсем((

можно попробовать вокруг вот этого поплясать: https://docs.gitlab.com/ee/ci/yaml/#cache но это уже такое, dark magic, имхо

не поделитесь примером как "надо"? Всё же так все и делают - собирают и гоняют одинаковые тесты на каждой ветке?

Я же писал, брать докер образ ветки мастер или там образ собранный и запушанный для предыдущего коммита и делать докер билд с —cache-from этого образа. Дальше докер уже раздуплит, если правильно слои сделаны то если код не менялся он скипнет шаги копирования и следующие шаги билда

в смысле?

Кеш фром образ предыдущего коммита

Подскажите, есть у kubectl какой-то verbose? Мастер очень долго отвечает на любой запрос, хочу посмотреть где именно подвисает.