Телеграмм чат группы ru_gitlab страница 2675

да

23:11пожаловаться #1

как я понимаю - да

23:11пожаловаться #2

в руби код я ес-но не смотрел

23:11пожаловаться #3

Ну а если два пайплайна, то как гарантировать то, чтобы второй всегда выполнялся после первого?

23:12пожаловаться #4

это решаемо переменными

23:13пожаловаться #5

и путями запсука

23:13пожаловаться #6

смотри

23:13пожаловаться #7

гитлаб-си файл по сути может включать в себя несколько пайплайнов

23:13пожаловаться #8

а через only/except ты можешь распилить - откуда пришел запрос на пайплайн

23:13пожаловаться #9

это первое

23:13пожаловаться #10

второе

23:13пожаловаться #11

или как @Andorka предложил гереить первой таской gitlab-ci.yml и считать хэш от него, если отличается тогда падать

23:14пожаловаться #12

если мы генерим пайплайн динамически, то как потом не сломать рестарт пайплайна

23:14пожаловаться #13

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

23:14пожаловаться #14

я бы ставил на то, что в include: http:///..../gitlab-ci.yaml можно было бы дописывать какие-либо переменные или json payload

23:14пожаловаться #15

и на основе него генерить стрктуру пайплайна

23:15пожаловаться #16

George Gaál

и на основе него генерить стрктуру пайплайна

Наверное можно просто следить за тем, чтобы .gitlab-ci.yml всегда обновлялся отдельным коммитом

23:18пожаловаться #17

можно

23:18пожаловаться #18

если обновилось что-то ещё, то генерить новый gitlab-ci.yml и падать

23:19пожаловаться #19

но как-то всё равно не очень clear