Дженкинс планирует несколько версий одной и той же сборки

#jenkins #triggers

#дженкинс #триггеры

Вопрос:

У меня есть проект, в котором постоянно работают 3-5 различных ветвей mercurial. Я хочу запланировать еженедельный тест Дженкинса, чтобы запускать наши тесты во всех соответствующих филиалах.

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

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

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

1. 3-5 different mercurial branches — вам нужно построить только определенные ветви или все доступные (я имею в виду, знаете ли вы названия ветвей, которые вы хотели бы построить)?

2. Только определенные. Он будет периодически меняться, но я буду знать названия ветвей.

Ответ №1:

Я могу предложить одно решение, но его нельзя назвать элегантным.

Во-первых, вам нужно создать multi-configuration project (он же Matrix project).
В этом проекте вам нужно объявить один node (это может быть уже существующий master узел)

И один тип axis (например BRANCH — будьте осторожны, не используйте переменные Jenkins Set Environment Variables) со значениями, соответствующими для каждой ветви (например default , testing , devel , и т. Д.).
После того, как вам нужно добавить в свой проект build действие, в котором вам нужно проверить environment переменную (ранее объявленную $ BRANCH ) и выяснить, для какой ветки была запущена эта сборка (основная идея проиллюстрирована примером с использованием bash ).
И, наконец, вам нужно вручную получить исходники из соответствующей ветки.
Следующие шаги сборки могут быть одинаковыми для всех ветвей.

У этого подхода есть ряд недостатков:
1. Вы не можете запустить этот проект путем изменений в репозитории (вы можете проверить, используя Mercurial plugin только одну ветку).
2. Все подпроекты будут перестроены, даже если они не претерпели изменений.
3. Подходит только для статически определенных ветвей.
4. Не элегантно.

Но у него есть одно преимущество по сравнению parameterized со сборкой:
1. Все артефакты (и журналы сборки) ветвей хранятся в отдельных каталогах (поскольку они являются отдельными подпроектами).