Size: a a a

2020 March 07

АК

Александр Кот in ru_gitlab
Bola
Друзья, подскажите.
Мне нужно сделать два процесса.
1. выкладка хотфиксов - если делается MR  в мастер ветку, то после аппрува и если нет мерж конфликтов - то произвести билд и деплой.
2. если MR в тестовую ветку - то нужно сделать: проверка, что нет мерж конфликтов, юнит тесты, билд на тестовый сервер (он один у нас) и e2e на этом сервере

Раннеры свои - пока создан один specific runner, который крутится на нашем сервере, поигрался, посмотрел - вроде работает

А вопросы у меня возникли: для пункта 1 - как сделать, чтобы проверился мерж на наличие ошибок (конфликты), потом произошел мерж, а потом остальные действия- билд и деплой на мастере
для п2 - на какие stages лучше разбить
и для обоих пунктов - какие правила прикрутить, чтобы срабатывали джобы строго по указанным условиям
Если мерж конфликты - вообще не хотите чтобы ни одна джоба запускалась?
источник

B

Bola in ru_gitlab
Да. Сразу стоп
источник

DV

Dmitry Vorobev in ru_gitlab
Разве можно заапрувить, если есть конфликты?
источник

B

Bola in ru_gitlab
А вот не знаю. И нужно, чтобы джоба стартовала после апрува
источник

АК

Александр Кот in ru_gitlab
Bola
А вот не знаю. И нужно, чтобы джоба стартовала после апрува
Можно стартовать джобу после мержа.
Можно до мержа стартовать тесты, даже если есть конфликты.
Исправив конфликты и запушив - у вас перезапустится джоба с тестами.
источник

DV

Dmitry Vorobev in ru_gitlab
А условие просто на коммит в мастер-ветку не подходит? Запротектить ее для девелоперов, чтобы напрямую не пушили и создавали MR 🤔
источник

B

Bola in ru_gitlab
Dmitry Vorobev
А условие просто на коммит в мастер-ветку не подходит? Запротектить ее для девелоперов, чтобы напрямую не пушили и создавали MR 🤔
Я так попробовал, чтобы мерж реквест именно в мастер, есть такая переменная. Джоба стартует, мерж становится в статусе Blocked, пока джоба не завершится. И тут я не пойму. То ли в этот момент все команды в джобе работают на ветке, которая в MR. То ли на мастере с коммитами ветки?
источник

DV

Dmitry Vorobev in ru_gitlab
Blocked не Merged, все на ветке. Да и дело не столько в MR. Исходя из постановки задачи, какие-либо действия надо предпринимать уже после того, как код попал в мастер. То есть, если есть конфликты, то гитлаб не позволить принять МР, какие-либо тесты для этого сценария не подразумеваются. Соответственно при принятии МР происходит обычный коммит в мастер, с которого можно запускать билд и деплой. Конечно, если я правильно вас понимаю
источник

B

Bola in ru_gitlab
Dmitry Vorobev
Blocked не Merged, все на ветке. Да и дело не столько в MR. Исходя из постановки задачи, какие-либо действия надо предпринимать уже после того, как код попал в мастер. То есть, если есть конфликты, то гитлаб не позволить принять МР, какие-либо тесты для этого сценария не подразумеваются. Соответственно при принятии МР происходит обычный коммит в мастер, с которого можно запускать билд и деплой. Конечно, если я правильно вас понимаю
Все верно. Звучит примерно так, как я представляю.
Тестов не будет. Так как Будут мелкие фиксы с ручной проверкой.
Получается, при мерж ничего не делаем, не надо к этому привязывать джобу. А сделать после коммита в мастер всю остальную кухню?
источник

DV

Dmitry Vorobev in ru_gitlab
Ну, вам виднее, но со стороны выглядит так. Конечно, если напрямую в мастер коммитов не делают, но это уже человеческий фактор. Максимум, что можно сделать, объявить мастер протектед веткой, соответственно доступ на принятие реквестов или пуши в мастер будет только у мейнтейнеров. Если это вам подходит, можно не костылить
источник

B

Bola in ru_gitlab
Dmitry Vorobev
Ну, вам виднее, но со стороны выглядит так. Конечно, если напрямую в мастер коммитов не делают, но это уже человеческий фактор. Максимум, что можно сделать, объявить мастер протектед веткой, соответственно доступ на принятие реквестов или пуши в мастер будет только у мейнтейнеров. Если это вам подходит, можно не костылить
Так и сделано. Доступ к мастеру только у мейнтейнера. И он пока один.
источник

B

Bola in ru_gitlab
А как сделать, чтобы не при каждом коммите в мастер запускался билд? Какими средствами ограничить поведение джоба?
источник

GG

George Gaál in ru_gitlab
[ci skip] добавлять в коммит ?
источник

GG

George Gaál in ru_gitlab
какой критерий ?
источник

B

Bola in ru_gitlab
George Gaál
какой критерий ?
Каталог с тестами
источник

GG

George Gaál in ru_gitlab
подробнее плз
источник

B

Bola in ru_gitlab
Если изменения касаются только тестов, то не билдить, точнее, вообще ничего не делать. Просто коммит в мастер
источник

B

Bola in ru_gitlab
Вариант с определенным названием коммита - тоже норм. Либо по названию ветки - этот вариант наверное лучше?
источник

DV

Dmitry Vorobev in ru_gitlab
Возможно вам подойдет https://docs.gitlab.com/ee/ci/yaml/#onlychangesexceptchanges
источник

B

Bola in ru_gitlab
George Gaál
[ci skip] добавлять в коммит ?
А как будет работать, если в ветке две коммита, один с skip, другой - без?
источник