У нас немного запутанная ситуация на нашей сборочной машине ...
Мне, наконец, удалось заставить работать одну матричную сборку, тип задачи «сначала проверить, что все компилируется», который просто компилирует все на текущей платформе, на которой она запущена. Он отлично работает на нескольких платформах (единственная проблема, которую он может иметь, заключается в том, что он многократно компилирует Java-код, хотя его, вероятно, можно было бы оптимизировать для этого один раз).
Я полагаю, что настроить матричную сборку для «установщиков сборки» тоже не составит большого труда.
Но есть две проблемы, которые обязательно коснутся.
Мы распространяем один zip-файл, который в идеале содержал бы все зависящие от платформы двоичные файлы в одном zip-файле, чтобы уменьшить дублирование (по сути, это библиотека, которую мы раздаем другим).
Процесс копирования текущих выпусков на сервер основан на том, что каждый сгенерированный файл с одним и тем же номером версии того же продукта будет готов до начала сборки. Никакая сборка для одной ОС не будет иметь достаточно полного представления о созданных файлах, чтобы можно было выполнить выпуск, и кажется невозможным добавить шаги сборки, которые выполняются в родительском задании.
Мы используем Archive for Clone Workspace SCM в качестве этапа после сборки для этой начальной сборки матрицы, но похоже, что это выполняется независимо в каждой ОС, и не предпринимается никаких попыток объединить результаты вместе.
Как другие люди решают все эти проблемы?
Я знаю, что могу полностью отказаться от построения матриц и сделать все, настроив несколько разных заданий, но сейчас у нас три платформы, и количество заданий резко возрастет.
Варианты, которые включают альтернативы Jenkins, также будут серьезно рассмотрены, так как в последнее время ... количество проблем, с которыми мы сталкиваемся, огромно.