Jenkins + Windows + CMake + несколько типов сборки (Debug, Release)

Как я могу заставить Дженкинса сделать следующее?

Проверить магистраль/из SVN, затем создать конфигурации Debug и Release с помощью CMake, не имея дублирующих заданий для конфигураций.

Ответ 1

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

Настройка по умолчанию в Jenkins заключается в том, что каждая сборка использует другой каталог в качестве рабочего пространства. Это означает, что вы выполняете полную проверку SVN каждой сборки. Который берет навсегда.

Если вы хотите использовать один и тот же исходный каталог для каждой сборки, вам нужно беспокоиться о синхронизации: только одна сборка за раз. Насколько мне известно, у Дженкинса нет встроенных средств синхронизации. Единственный способ - использовать только одного исполнителя. Даже тогда вы не можете контролировать способ, которым исполнитель выбирает следующую работу.

Предположим, что работа "SVN update" запускает задание "Build". Кто-то запускает "SVN update # 33", который должен запускать "Build # 33" . Если, однако, функция "Опрос SCM" Дженкинса планирует "обновление SVN" № 34, я не нашел способа сказать, что "Build # 33" должен выполняться до "SVN update # 34". Таким образом, вы можете запустить "Обновление SVN № 34" до "Build # 33" , и все не удастся. Если вы вручную не отключите задание на опрос. И напомните себе, чтобы потом снова включить его.

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

Ответ 2

Пришло время понять это. Вот как мне это удалось.

Создать бесплатную работу "Оформить заказ". Эта работа будет делать все, что не зависит от типа конфигурации (Debug/Release).
В разделе "Управление исходным кодом" выберите Subversion
Введите URL-адрес репозитория. Вероятно, это хорошая идея, чтобы он указывал на/туловище.
Установите локальный модуль в директорию "." (без кавычек)
Как стратегия выезда "Эмулировать чистоту" приятно
Создайте триггер опроса SCM, установите расписание на "5 * * * *", чтобы проверять каждые 5 минут.
Теперь в разделе "Дополнительные параметры проекта" установите флажок "Использовать настраиваемое рабочее пространство" и установите каталог, например. "C:/ЦСИ". Мы не хотим, чтобы Дженкинс использовал внутреннее рабочее пространство, потому что мы хотим, чтобы другие задания имели доступ к источнику.
В разделе "Сборка" добавьте следующую командную команду Windows, которая используется для очистки директории сборки. По какой-то причине CMake не предоставляет способ сделать это.
```
cd c:\
rmdir /S /Q build
mkdir build
cd build

cmake --version
rem optionally: svn info c:\src
cmake -G "Visual Studio 10" c:\src
```
Создайте еще одно задание "Build", на этот раз сделайте это "многоконфигурационным" заданием. Это задание будет выполняться для каждой конфигурации (Debug/Release).
Сначала установите Build Triggers для сборки после задания "Checkout"
Теперь в Мастере конфигурации добавьте ось "configuration" со значениями "Debug Release" (whitespace = separator). К сожалению, плагин построителя CMake для Jenkins не работает с заданиями с несколькими конфигурациями. Мы даже не можем использовать cmake -build, потому что он всегда создает конфигурацию Debug. Для сборки мы должны использовать другую партию script:
```
cd c:\build
call "%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"
msbuild ALL_BUILD.vcxproj /verbosity:minimal /maxcpucount:1 /property:Configuration=%configuration%
```

Если вы хотите построить полное решение, укажите файл .sln вместо ALL_BUILD.vcxproj. Если вы хотите создать конкретный проект, используйте

    msbuild <solution>.sln /target:<project>

Ответ 3

Используйте Работа с матрицей Jenkins. Определите одну из осей как build_mode со значениями Debug и Release. Затем вы запускаете CMake, который будет создавать обе конфигурации для инструмента компиляции, который вы будете использовать (XCode, gcc, VisualStudio и т.д.). Затем вы можете использовать build_mode, как если бы это была переменная среды, и передать ее для создания шагов, которые выполняют фактическую компиляцию.

Ответ 4

При использовании генератора Visual Studio вы можете передать конфигурацию для сборки в cmake --build -command:

cmake --build . --config Release
cmake --build . --config Debug

См. также Документы CMake.