Ответ 1

Похоже, что существует облегчение, достигаемое, по крайней мере, с помощью BlueOcean UI. Вот что я получил (узлы tk-* являются параллельными шагами):

Ответ 2

TL;DR: Jenkins.io хочет, чтобы вы использовали узлы для каждой сборки.

Jenkins.io: В контекстах конвейерного кодирования "node" - это шаг, который выполняет две вещи, как правило, путем привлечения справки от доступных исполнителей на агенты:

• Запускает шаги, содержащиеся в нем, чтобы запустить их, добавив их в очередь сборки Jenkins (так что, как только слот-исполнитель свободен на node, выполняются соответствующие шаги)

• Лучше всего выполнять всю материальную работу, такую ​​как создание или запуск сценариев оболочки, в узлах, поскольку node блокирует на этапе рассказать Дженкинсу, что этапы внутри них являются ресурсоемкими достаточно запланировать, запросить помощь из пула агентов и заблокировать рабочую область только до тех пор, пока она им нужна.

Ваниль Дженкинс node блоки на сцене будут выглядеть так:

stage 'build' {
    node('java7-build'){ ... }
    node('java8-build'){ ... }
}

Дальнейшее расширение этого понятия Cloudbees пишет о parallelism и распределенных сборках с Jenkins. Рабочий процесс Cloudbees может выглядеть так:

stage 'build' {
    parallel 'java7-build':{
      node('mvn-java7'){ ... }
    }, 'java8-build':{
      node('mvn-java8'){ ... }
    }
}

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

ИЗМЕНИТЬ

Чтобы обратиться к визуализации @Stephen, хотелось бы видеть, он прав - это не работает! Вопрос был поднят с помощью Jenkins и описан здесь, разрешение использования использования "помеченных блоков" все еще продолжается:-(

Q: Есть ли документация, позволяющая пользователям конвейера не ставить этапы внутри параллельных шагов?

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

Если вы попытаетесь использовать сцену в параллельном задании, у вас будет плохое время.

ERROR: The ‘stage’ step must not be used inside a ‘parallel’ block.

Ответ 3

Чтобы проверить каждую фиксацию на нескольких платформах, я использовал этот базовый скелет Jenkinsfile:

def test_platform(label, with_stages = false)
{
    node(label)
    {
        // Checkout
        if (with_stages) stage label + ' Checkout'
        ...

        // Build
        if (with_stages) stage label + ' Build'
        ...

        // Tests
        if (with_stages) stage label + ' Tests'
        ...
    }
}

/*
parallel ( failFast: false,
    Windows: { test_platform("Windows") },
    Linux:   { test_platform("Linux")   },
    Mac:     { test_platform("Mac")     },
)
*/

test_platform("Windows", true)
test_platform("Mac",     true)
test_platform("Linux",   true)

С этим относительно легко перейти от последовательного к параллельному исполнению, каждый из которых имеет свои плюсы и минусы:

• Параллельное выполнение выполняется намного быстрее, но оно не содержит метки этапов
• Последовательное выполнение выполняется намного медленнее, но вы получаете подробный отчет благодаря этапам, обозначенным как "Проверка Windows", "Windows Build", "Windows Tests", "Mac Checkout" и т.д.).

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

Ответ 4

Как отмечено @StephenKing, Blue Ocean будет показывать параллельные ветки лучше, чем текущий вид сцены. Планируемая наступающая версия представления сцены сможет отображать все ветки, хотя она не будет визуально указывать какую-либо структуру вложенности (будет выглядеть так же, как если бы вы запускали конфигурации поочередно).

В любом случае, более глубокая проблема заключается в том, что вы по существу получите только статус pass/fail для сборки в целом, до разрешения JENKINS-27395 и связанных с ним запросов.