Jenkins, склеивание коммитов в задании при ожидании в очереди.

Такая проблема:
Женкинс опрашивает репозиторий каждую минуту, при поступлении коммита запускается задание и пошли тесты (продолжительность от 1 мин. до 1 часа), если в период тестирования поступают коммиты то они склеиваются в одно задание

Может кто знает, как заставить женкинс ставить в очередь задания на каждый коммит?

ЗЫ: Сборщик только один, распаралеливание невозможно по некоторым причинам.

Не бывает невозможности распараллеливания, только если у вас тупо нет серверов для этого :smile:

К теме - там случайно не свн?

На данный момент нет возможности распаралелить (все упирается в БД, одна на всех и вся и не маленького объема около 160 гиг).

Да SVN.

Это фича с полингом из свн (с)

Как у вас сейчас настроено все? как выглядит пост коммит хук?

Еще одна проблема, никаких хуков нет и не предвидится :frowning:

ЗЫ: Изменения допускаются только в самом женкинсе.

Почему в свн нельзя добавить 1 файл с хуком?О_о

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

Ждемс еще варианты.

Я не понял, а что у вас можно сделать? Если ничего сделать нельзя, то как можно пофиксить? Ментально? :smile:

1 лайк

В Git Plugin такая фича есть: git-plugin/RevisionParameterAction.java at 4979aced9de77f487318c4ba51aaa386e56bffc7 · jenkinsci/git-plugin · GitHub . В зависимости от опций задачи с одинаковыми коммитами мерджатся или нет.

В SVN плагине реализации нет. При желании подобное можно сделать через pull-request или же через свой плагин (первое предпочтительнее).

Отвечающий за дубликаты кусок кода в ядре: jenkins/Queue.java at 7c9ba7011cb905adc6d39321dc68b3a202daa3de · jenkinsci/jenkins · GitHub

Возможно проблема в том, что Jenkins в принципе склеивает последовательные задачи в очереди, если те не отличаются параметрами запуска.
Есть плагин Random String Parameter Plugin, который к сборке добавляет параметр со случайно строкой, что препятствует склейке сборок из очереди.

2 лайка

Не совсем помогло, начало создавать раздельные задания в очереди но в итоге выкатывается несколько коммитов вместе.

Как раз это и было написано выше, может просто не до конца поняли @oleg_nenashev.

За плагин спасибо, интересно, есть ли еще ему применения? :slight_smile:

Очень странно почему изначально нет возможности использовать post commit hook.
Если есть желание поллить коммиты, то как сказал @st_eremin одна джоба будет иметь поллер, где шагом сборки будет запуск другой сборки (через rest api jenkins). В этом случае склеивания коммитов быть не должно, но раз уж Дженкинс позволяет создавать параметризированные сборки, то тогда уж вместо предложенного выше random string parameter передавайте хэш коммита в кач-ве “различителя” и пишите echo с инфой данного коммита.

На самом деле столкнулся с той же проблемой. Однако у меня Jenkins в связке с гитлабом, установлен GitLab Plugin.
Сам дженкинс сразу реагирует на изменения в репозитории, но, допустим, если во время сборки поступило еще минимум 2 коммита, то они, как писал @NickAb склеиваются, что есть очень и очень не в тему
Вообще я пробовал распараллеливание и да, это работает. Но все же нужно чтобы все сборки выполнялись последовательно, при этом не хочется наступать в велосипед. По идее каждая сборка в очереди должна запоминать номер коммита, от которого ей следует отталкиваться (иначе просто в очереди будет несколько задач, которые будут собирать одно и то же).

Ребята, выручайте пожалуйста :slight_smile:

Я решил эту проблему на 99%, иногда проскакивают единовременные коммиты, из-за паузы перед запуском джобы в Жене (Jenkins). Добился все-таки (почти 9 месяцев убалтывал, как ребенка выносил :slight_smile: ) чтоб сделали мне хук на aftercommit, который толкает женю, но это не решило проблему так как хук сделали простым без параметризации :frowning: .
Но решил уже это по своему, создал отдельную джобу, назвал ее Provisor_“PojecName”, который смотрит в нужный репозиторий и отлавливает пинки от хука, и эта джоба потом вызывает основную джобу с передачей параметра № ревизии. Да чуть не забыл, чтоб этот провизор тоже не склеивался, я создал слейв с 2-мя сборщиками и применил Random String Parameter Plugin:



А сома вызываемая джоба имеет параметр и настроена на тот-же репозиторий с применением этого параметра (без автоопроса):


Ну как-то так :slight_smile:, жду вопросы.

1 лайк

Даааа, вопросы будут)
Смотри, зачем использовать для провизора слейв и рандом-строчку, во первых? Просто как бы и параллельная сборка, и унивкальные билды.
Во вторых, можно ли обойтись без слейва? Если же нет, сам джоб, который билдит, должен ли быть подключен к тому же слейву?
По факту для Git это должно работать абсолютно также, ведь так? И ты писал, что есть aftercommit хук. Он задействован у тебя или нет?

Т.к. наши рукоблудцы часто много коммитов делают, то чтоб основной сборщик собирал проекты последовательно и не упирался в провизор то ему (провизору) выделил отдельный слейв. Рандом строчка для провизора чтоб несколько коммитов не склеивало в один для себя.

В твоем случае да, добавь еще пару сборщиков и все.

Глубоко фиолетово, этож все в одном центре.

Ессесно.

1 лайк

ох, спасибо тебе огромное!
Сейчас попробую настроить это все и потом отпишусь

Спасибо огромное решение работает.
Для гитлаба нужно сделать в исполняемом билде вот такую настройку:

1 лайк