Многоканальная сборка Jenkins не обнаруживает изменений в репозитории

У нас есть репозиторий Subversion в этом поместье:

  • http://svn.vegicorp.net/svn/toast/api/trunk
  • http://svn.vegicorp.net/svn/toast/api/1.0
  • http://svn.vegicorp.net/svn/toast/data/trunk
  • http://svn.vegicorp.net/svn/toast/data/branches/1.2
  • http://svn.vegicorp.net/svn/toast/data/branches/1.3

Я установил сборку Jenkins Multi-Pipeline для всего проекта toast, включая все подпроекты - каждый подпроект представляет собой файл jar. Я хочу, чтобы Дженкинс запускал новую сборку каждый раз при изменении любого файла в одном из тостовых проектов. Этот проект следует перестроить. Таким образом, если мы создадим новый подпроект в toast или новую ветку в одном из подпроектов toast, Дженкинс автоматически создаст для этого новую сборку.

Вот моя установка Jenkins Multi-Branch:

Источники веток

Subversion

  • База репозитория проекта: http://svn.vegicorp.net/svn/toast
  • Учетные данные: builder/*****
  • Включить ветви: */trunk, */branches/*
  • Исключить ветви: */private
  • Стратегия в отношении свойств: Все ветви имеют одинаковые свойства

Конфигурация сборки

  • Режим: Автор Jenkinsfile

Триггеры сборки (Не выбрано)

  • Триггер строит удаленно (например, из скриптов) Справка по функции: Триггер * строит удаленно (например, из скриптов)
  • Периодическая сборка Справка по функции: Периодическая сборка
  • Сборка при продвижении другого проекта
  • Справка по триггеру обновления зависимостей Maven для функции: Триггер обновления зависимостей Maven
  • Периодически, если иначе не запускать

Обратите внимание, что список Триггеры сборки не включает SCM опроса. Изменения в репозитории не вызывают сборки. Jenkinsfiles находятся в корне каждого подпроекта. Если я принудительно переиндексирую, будут построены все измененные подпроекты и найдены все новые ветки. Изначально я проверял Периодически и переиндексировал каждую минуту, чтобы уловить изменения, но это глупо и, похоже, заставляет Дженкинса потреблять память.

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

Должно быть что-то действительно простое, чего мне не хватает.

Конфигурация:

  • Дженкинс 2,19
  • Трубопровод 2.3
  • API конвейера: 2.3
  • Конвейер Groovy: 2.17
  • Работа на конвейере: 2,6
  • Плагин Pipeline REST API: 2.0
  • Общие библиотеки Groovy конвейера: 2.3
  • Конвейер: плагин Stage View: 1.7
  • Конвейер: поддержка API 2.2
  • Плагин SCM API: 1.2

person David W.    schedule 21.09.2016    source источник


Ответы (3)


Я наконец нашел ответ. Я нашел запись в Jenkins 'Jira Database, в которой упоминается именно эта проблема. Проблема называется опрос SCM не выполняется в многоотраслевом конвейере с Mercurial SCM. Вмешались и другие пользователи.

Ответ заключался в том, что для проектов Jenkins с несколькими ветвями не нужно опрашивать SCM, потому что индексация ветвей делает это за вас:

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

Итак, мне нужно настроить переиндексацию веток. Я не доволен этим решением, потому что оно кажется довольно неуклюжим. Я могу добавить хуки post-commit и post-push в SVN и Git, чтобы запускать сборки при изменении, а затем периодически переиндексировать (скажем, раз в час). Проблема заключается в настройке этих хуков и последующем их обновлении. Каждому проекту требуется собственное действие POST, что означает обновление сервера репозитория при каждом изменении проекта. С опросом мне не нужно было беспокоиться об обслуживании крючка.

person David W.    schedule 29.09.2016
comment
Вы можете просто позволить своим хукам postCommit запускать индексацию веток, которая, в свою очередь, запустит сборку. - person Patrick Cornelissen; 19.03.2017

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

Сам по себе Jenkins не может просто знать, когда были внесены изменения в репозиторий. Репозиторий необходимо настроить для широковещательной рассылки при внесении изменений. Веб-перехватчик определяет URL-адрес, на который репозиторий может отправлять различные биты информации. Укажите URL-адрес, который может прочитать Дженкинс и который позволяет Дженкинсу отвечать на определенные типы информации, которую он получает.

Например, если вы использовали github, вы могли бы заставить Дженкинса прослушивать URL-адрес, такой как https://my-jenkins.com/github-webhook/. Github можно настроить на отправку POST сразу после открытия PR или выполнения слияния. Этот POST не только символизирует, что действие было выполнено, но также будет содержать информацию о действии, такую ​​как SHA, имя ветки, пользователь, выполняющий действие ... и т. Д.

И Jenkins, и SVN должны иметь возможность определять URL-адрес, каждый из которых POST и прослушивает соответственно.

Мои знания связаны с git. Но это может быть хорошим началом для веб-перехватчиков SVN: http://help.projectlocker.com/knowledge_base/topics/how-do-i-use-subversion-webhooks

person Julian    schedule 29.09.2016
comment
Вы говорите о хуках после фиксации в Subversion и push-хуках в Git. Оба могут быть настроены для выполнения сценария (который может отправлять HTTP) всякий раз, когда выполняется push или фиксация. Однако это не требуется для заданий Jenkins Freestyle и Maven. Дженкинс может запросить само репо и посмотреть, есть ли изменения. - person David W.; 30.09.2016

Возможно, вам нужно что-то под контролем версий в базовом каталоге. Попробуйте поместить сюда тестовый файл http://svn.vegicorp.net/svn/toast/ test.txt. Это может привести к появлению опции SCM опроса.

person John Meyer    schedule 29.09.2016