Jenkins Частичная сборка/модульная сборка на фиксаторе

Question

Инструменты:
Jenkins ver. 1,470
Maven 2
Subversion

Environment

Предположим, моя сборка имеет ряд проектов A-D. График зависимости существует, как показано. То есть: B зависит от классов в A, C зависит от классов в B, D зависит от классов в A. Мы создаем сборки дженкинсов, которые они называет зависящими от них строками как действие после сборки.

| -> B -> C
| -> D

Каждую ночь, мы вызываем полное построение в Дженкинс (A строит, запускает B (триггеры C), триггеры D). Это делается достаточно легко, говоря А строить ночь, а остальные каскады.

Проблема

Однако на коммит мы хотим строить проекты, которые были совершены в один раз.

• Ситуация 1: Мы опрашивать хранилище (или использовать commit hooks, это не имеет никакого значения) и найти, что существует обязательство B, то B будет строить и C будут строить. Успех!

• Ситуация 2: Мы опрашивать хранилище и обнаружить, что B и C были совершены в один коммит, то Дженкинс будет пытаться построить B (запуская сборку C), и построить C (второй сборки). Неисправность. Посмотрите, что произойдет? C был построен дважды, занимая драгоценное время строительства. Храните строение быстро!

Кто-нибудь знает способ только вызвать самый высокий проект в каждом совершенном трубопроводе сборки?

Я полагаю, решение будет сложным СВН крюк, который определяет высокий проект в каждом конвейере ...

• Ситуация 3: Передайте B C и D в один коммит. SVN-крючок обнаруживает, что C зависит от B. Крюк вызывает ссылки на конкретные проекты для запуска сборок для B и D.

Ловушки: очень сложный захват SVN. Имейте, чтобы поддержать трубопровод в крюке SVN.

Я чувствую, что это проблема, с которой сталкиваются другие. Есть ли плагин Jenkins, который помогает с этим?

Answer 1

Было бы интересно сказать, что дженкинсы ждут с сборкой до тех пор, пока не будет завершена сборка c. Для этого используется флаг в конфигурации задания. Но вы должны сделать это для каждой работы. Btw ...есть еще один флаг, который требует от jenkins ждать со сборкой до завершения задания зависимости.

Answer 2

Я также ищу эффективное решение этой проблемы. Я видел несколько предложений, но до сих пор нам удалось избежать одной из ошибок, сериализовывая сборку, используя плагин Locks & Latches. Это не мешает проекту создавать несколько раз из одной проверки, но это гарантирует, что проект будет восстановлен последовательно после завершения проекта по восходящему потоку.

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

Лучшим вариантом будет плагин, который автоматически управляет очередью сборки, основываясь на вашем графике зависимости. Это может быть сложно, потому что вам необходимо убедиться, что сборка не начнется до тех пор, пока все ее зависимости не будут завершены. По сути, это означает, что каждый checkin заставит плагин автоматически добавлять все последующие сборки в очередь, чтобы он мог управлять ими. Возможно, есть умный и простой способ сделать это с существующими триггерами вверх/вниз по течению, но мне пока не ясно, как это сделать. Есть уже готовые плагины конвейера, которые утверждают, что справляются с этой ситуацией, но они явно ничего не делают, чтобы предотвратить состояние гонки, когда нисходящая сборка может быть вызвана тем же контролем, что и восходящая сборка.