Как проверить, готов ли merge request к объединению в Gitlab CI?

Как сделать так чтобы при создании merge request - создавалась например третья ветка из master, затем мержились туда изменения из ветки test-branch и запускались тесты?

результаты такого теста становятся неактульны после любого мерджа в мастер, так что с точки зрения workflow это тоже самое что поребейзить свою ветку перед созданием pull request

Так после любого мержа в мастер - я думаю нужно запускать тестирование merge request.

Что характерно в svn плагине для дженкинса была такая галка :)

Лучше тогда ребейзить каждый PR после мерджа. Для этого в принципе легко бота написать. Более наглядно и удобно для дебага.

Ребейз зло, особенно такой

Как сделать так чтобы при создании merge request - создавалась например третья ветка из master, затем мержились туда изменения из ветки test-branch и запускались тесты?

В Гитлабе сейчас никак.

Фичреквест: https://gitlab.com/gitlab-org/gitlab-ee/issues/3709

Вся мякотка появляется на средних и выше проектах, когда целевая ветка обновляется часто.

Если у нас висят 100 мердж-реквестов на мастер, то при очередном обновлении мастера нужно запускать сразу 100 пайплайнов для этих мердж-реквестов, чтобы показать актуальные результаты: «можно мерджить / нельзя мерджить».

И не факт, что во время прогона этих пайплайнов кто-нибудь не обновит мастер снова.

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

Есть такая штука - гейтинг, когда тесты прогоняются не только в момент создания реквеста, но в момент его аппрува перед окончательным мерджем. Патч ребейзится на мастер, результат тестируется и если всё ок - сразу же мерджится. Таким образом мы не перезапускаем все патчи тестировать на каждый мердж, но тем не менее исключаем возможность непротестированного кода.

При этом его можно сделать условно-параллельным, на хороших реквестах.

Искать по слову Zuul. Можно начинать отсюда со слайда про speculative gating https://archive.fosdem.org/2014/schedule/event/openstack_testing_automation/

Но хороших реализаций у него - практически только OpenStack и есть.

Для мелких проектов такая система не окупается, поскольку логика непростая, а изкоробочного варианта ни в одной готовой CI-системе нет.

С чего бы это.

Да, но в данном случае страдает удобство.
О чём я и сказал выше про компромисс.

Очевидно в этом случае можно прийти к неконсистентной конфигурации (если, конечно, мержи в основную ветку не происходят одним коммитом)

А на jenkins точно такого нет?

Встроенного механизма нет, плагинов тоже не встречалось. Zuul как раз и был изначально надстройкой над дженкинсом.

В принципе простой вариант гейта можно реализовать кастомной логикой, если отобрать у разработчиков права на мердж и оставить их только у дженкинса. Тогда для того чтобы замерджить нечто ты не кнопку merge жмешь, а пишешь комментарий: «патч одобрен». На этот комментарий триггерится таска в дженкинсе, выполняет тест. Если этот тест проходит - дженкинс мерджит патч. Таска должна быть с запретом concurrency и выполняться всегда последовательно.

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

Так сам гейт будет действующим, а вот спекулятивность/параллелизацию для него силами дженкинса крутить - это практически переделать всю его логику планировщика. По-простому не получится.

Неконсистентность чего с чем?

В таком подходе ты после ребейза получаешь новый PR который требует нового ревью и нового теста. Если патч при ребейзе развалился - он требует ручного разбора конфликтов.

Ну и разумеется, чем ближе ты к CI, тем короче должны быть ветки на pull-request. Ветки по 130 коммитов ребейзить сложно, но их и банально мерджить и интегрировать сложно. Подход с постоянным ребейзом как раз мотивирует не копить изменения неделями, а держать их постоянно актуальными.

Что вы думаете об этом плагине? https://wiki.jenkins.io/display/JENKINS/Pretested Integration Plugin

я его не тестировал.

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

Если я правильно понимаю, это как раз простой гейт, только вместо комментов в какой-то системе ревью типа GitLab или GitHub там для признания ветки одобренной и запуска гейта используется просто регэксп по наименованию веток.

Это сразу делает такой плагин несовместимым с большинством ревью-систем BitBucket, GitLab, GitHub, Gerrit.. все они работают иначе и визуализации процесса ревью так не получить.

На вопросы типа «а кто и когда создал ветку ready/...» оно не отвечает. То есть их подход работает, когда разработчик сам решает, что ему пора мерджиться, без участия коллег.

Неконсистентность чего с чем?

Истории с изменениеями, очевидно же.

В таком подходе ты после ребейза получаешь новый PR который требует нового ревью и нового теста. Если патч при ребейзе развалился - он требует ручного разбора конфликтов.

Порой API может быть сломан и без всяких конфликтов.

Ну и разумеется, чем ближе ты к CI, тем короче должны быть ветки на pull-request. Ветки по 130 коммитов ребейзить сложно, но их и банально мерджить и интегрировать сложно. Подход с постоянным ребейзом как раз мотивирует не копить изменения неделями, а держать их постоянно актуальными.

Это всё красиво в теории, а вот на практике предлагаю сделать такое упражнение:

                          API Breaker!    merge «branch» to «master»
                             :              :
master-->1-->2--->3--------->4---->5--------6------
            \                      \      /
branch        a---->b-->c----->d--->d'-->e
                                    :
                            merge «master» into «branch»

Есть две ветки, основная, которая жила своей жизнью, и васина. В девелоперской в коммите d внесли регрессию (которую заметят только потом), в мастере изменили API в коммите 4.

Программист Вася перед мержом смёржил к себе мастер, прошёл ревью и залил всё обратно.

Проходит месяц, обозначается регрессия, которая покрывается тестом и надо её выявить. Пишется скрипт с бисектом и пошло дело:

bisect: 1 good, 6  bad

try 4 : 4 good, 6  bad (in 4..6)
try c : c good, e  bad (in a..e)
try d': c good, d' bad (in c..d')
try d : d bad,  d' bad (d is regression)

О-па и нашли где собака зарыта. Вася молодец, Вася не использовал ребейс, и бисект по цепочке мержей не сломался посередине из-за того, что в коде оказались коммиты, которые были сделаны _после_ изменений API но не готовые к нему. При итерации по a..e код в HEAD-е будет именно в том виде, в каком его видел Вася месяц назад.

А теперь, любители ребейса, скажите мне, что станет с бисектом, если бы Вася отребейзил всю ветку на новый HEAD и опосля пофиксил ошибки компиляции?

А теперь, любители ребейса, скажите мне, что станет с бисектом, если бы Вася отребейзил всю ветку на новый HEAD и опосля пофиксил ошибки компиляции?

Ты плохо прочитал, попробуй ещё раз.

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

1) workflow основанный на ребейз не означает делаем всё то же, что раньше, только заменяем merge на rebase. Он означает - делаем обозримые изменения, не задерживаемся в ветке и оперативно обновляем всё, что не замерджено.

Ты подразумеваешь картинку типа такой:

master-->1-->2--->3-->4--->5---a'---->b'-->c'----->d'-->e'-----6------

Где a'-d' - это автоматически обновленные, но протухшие коммиты.

Правильная картинка при rebase-workflow такая:

master-->1-->2-->a->3--b>-->4-->d-->5--->e-->6------

Коммиты замерджены, тогда когда сделаны. Они не должны протухать.

Разумеется при этом структурировать содержимое коммитов надо немного иначе. Это называется Continuous Integration.

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

Этот пункт к теме разговора вообще не относится.

Коммиты замерджены, тогда когда сделаны. Они не должны протухать.

Посыл верный, и где-то в стране эльфов наверное даже есть проект, в котором это действительно так :)

Это называется Continuous Integration.

Да ладно!

Посыл верный, и где-то в стране эльфов наверное даже есть проект, в котором это действительно так :)

Посмотри любой проект хостящийся на Gerrit. Например Android или OpenStack. В нем rebase - это базовая вещь.

GitHub по UX, организации тестирования и разработки где-то в позапрошлом веке. К сожалению это сказывается на привычках его пользователей, но это не значит, что это единственно верный и единственно «реальный» подход.

Посмотри любой проект хостящийся на Gerrit

О, это сразу многое объясняет.

Если серьезно, то работал с ним где-то с год, наверное, не могу сказать, что мне это понравилось.

В нем rebase - это базовая вещь.

Ибо ревью льется одним коммитом (за исключением мержа).

GitHub по UX, организации тестирования и разработки где-то в позапрошлом веке. К сожалению это сказывается на привычках его пользователей, но это не значит, что это единственно верный и единственно «реальный» подход.

Геррит в таком разрезе можно назвать вообще возвращением к корням, к СВНу. Но почему прогрессивные экстремальные программисты не использует СВН?

Геррит в таком разрезе можно назвать вообще возвращением к корням, к СВНу. Но почему прогрессивные экстремальные программисты не использует СВН?

Потому что ты путаешь review-систему и систему контроля версий. Геррит - это не про то, что лучше, Git, SVN или mercurial, это про то как ты организуешь процесс разработки.

Gerrit заточен под CI-процесс и он делает CI простым. GitHub делает CI неочевидным и сложным. Поэтому для него разговоры на тему атомарных патчей, оперативного ревью и расширенного тестирования, гейта и всего прочего кажутся «эльфийскими». При том что практике CI сто лет в обед и она давно успешно себя зарекомендовала.

Потому что ты путаешь review-систему и систему контроля версий.

Нет

Геррит - это не про то, что лучше, Git, SVN или mercurial, это про то как ты организуешь процесс разработки.

Да.

И с герритом процесс разработки всё более напоминает тот, что обычно естественно протекает при использовании svn

При том что практике CI сто лет в обед и она давно успешно себя зарекомендовала.

Не спорю, но

разговоры на тему атомарных патчей, оперативного ревью и расширенного тестирования, гейта и всего прочего

Вполне справедливы и без геррита

Вполне справедливы и без геррита

И это ты мне говоришь. Забавный поворот дискуссии на 180 градусов.

А вот этот плагин https://github.com/timols/jenkins-gitlab-merge-request-builder-plugin как вам?

Судя по описанию этот плагин решает как раз ту задачу, что ты описал в топ-посте: в момент создания/обновления pull-request-а сделать мердж на target branch и тестировать то, что получилось.

Это в общем и без плагинов легко делается. Главное чтобы переменная targetBranch или destinationBranch или как угодно её назови была доступна во время исполнения теста.

Но это не гейт, это просто такой вариант тестирования патча, и я там выше писала своё имхо, что это не та задача которую надо решать.

Потому что результат теста при обновлении мастера не обновляется.

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