По таймауту деплоя запускать деплой?)

по таймауту после тестов

Хммм, хорошая идея)) Буду иметь ввиду, спасибо)

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

Ладно, спасибо всем, буду пытаться отговорить бизнес и как-то оптимизировать тесты..

Но если никак, то таймауты мое все 😊

я не в курсе костылей таких, но думаю что хуже не будет)

не подскажете, как сделать так, что бы в пайплайне в случае ручного аппрува делался мержреквест в ветку нужную
кейс -
поднимается апп на тестинг. Когда его руками протестировали, то тыкаем кнопку, что все ок и тогда эти изменения мержатся в нужную ветку ( или делается мержреквест)

Да просто кнопку мержа дайте тому кто тестирует, а дальше на его совести

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

кейс примерно такой

1. stage: test-build -  билдится внутри докера приложение. определяются артифакты
2. stage: test-package  Далее их нужно вручную протестировать.
Правильно ли будет:  создать имадж, запушить в режистри

3. Stage: test-deploy -  развернуть образ с не большим исправлением на стейдже, что бы каждый кто делает минифичу смог ее сам руками протестировать.
зайти руками потестить ( и тут у меня загвоздка тк не знаю как правильно это реализуется)
на стейдже начинает крутиться тестовый образ, при этом джоба считается суксес ( ведь имадж развернут и можно заходщитьи руками тестить)

4. Stage: Merge-to-prerelease - Если руками проверили и все ок, то изменения мержатся в пре-релизную ветку по кнопке.  ( но остается на стейдже крутиться тестовый образ, как его убить тогда?) Не знаю, как это обычно гитлабсиаем  делается.

В пре-релизной ветке собираются не большие изменения, которые в конце пайплайна должны будут по кнопке смержиться в релизную, все это обернуться в релизный имадж и задеплоиться на прод.

5. Stage: release-build - билдятся все изменения из релизной ветки  при мердже из pre-release (only: release)
6. Stage: release-package - собирается релизный имадж (only: release)
7. Stage: release-deploy - деплоится на прод по кнопке (only: release, when: manual)

это примерно то, как я вижу стейджи. не знаю рационально ли все это.
Суть в том, что несколько разработчиков кодят свои минифичи и могут раздеплоить их на стейдже. Когда накапливается достаточно фич в пре-релизной ветке ( которые 100% протестирвоаны и готовы к проду) то при мердж-реквесте в релизную - собирается образ со всеми правками от разрабов и деплоится на прод ( или на стейдж для 100% убеждения, что все ок и далее на прод)

сможет кто суппортнуть, я бы поблагодарил)))

Возьму $60 в час :)

он поможет

мне нужно не сделать за меня, а советом подмогнуть)

спасибо, попробую обратиться

Консультации — $60 в час :)

спасибо

Так в чём вопрос? Как нужно, так и делай? Или что? Тут все индивидуально же, конечно есть некоторые паттерны, идеи, устоявшиеся реализации. Но опять же, детали - индивидуальны.

Ребят, а кто ставил helm гитлаб, как правильнее прокинуть энвайроменты там для юникорна и движка вебхуков,хотел  прокси прописать

давай конкретнее - какой хельм юзаешь