2015-09-30 6 views
1

Я потратил несколько дней, пытаясь использовать разные подходы, чтобы получить триггер Jenkins, когда мы принимаем запрос на объединение. К сожалению, я не могу заставить ничего работать в нашей системе. Я пробовал разные плагины от стороны Jenkins, чтобы вызвать GitLab, но они, похоже, тоже не работают. Добавляя параметризованные строки и добавляя токен к концу URL, я пробовал их все - возможно, не в правильном порядке, я не уверен.Как запустить Jenkins начать сборку после запроса слияния GitLab

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

Затем, следующий вопрос: как отлаживать то, что происходит от GitLab до Jenkins? Вы смотрите на системные журналы? Кажется, там много чего, и то же самое с файлом /var/log/Jenkins/jenkins.log.

Любая помощь/предложения очень ценится. версия 7.12.2 Дженкинс::

GitLab версия 1,620

+0

Вы используете GitLab Community Edition или Enterprise Edition? Если вы используете Enterprise Edition, вы можете ознакомиться с этой документацией: http://docs.gitlab.com/ee/integration/jenkins.html В нем содержатся инструкции по настройке сервиса Jenkins CI. К сожалению, Community Edition не имеет этой службы. –

ответ

0

Я знаю, что это старый вопрос, но вот мои настройки для этого на GitLab CE 8.13.12 и Дженкинс 2.46.2 использованием declarative pipelines и Плагин Gitlab 1.4.5 и плагин Gitlab Hook 1.4.2. Эти шаги, вероятно, будут работать и с последней версией.

  • Два отдельных рабочих мест трубопроводов
    • Первая работа специально для MR построить
    • Второй для главного филиала/репо, где MR получает объединены в
  • Оба рабочих мест имеют встроенный триггер «Сборка при внесении изменений в GitLab».
    • В задании MR есть ссылка вследствие событий позволило
      • Merge запрос событий (и перестраивать на толчке к источнику и цели)
      • Комментариев (и некоторым комментариям)
    • Мастер Работа только имеет толкающее событие триггера включено, но и усовершенствованный вариант для фильтрации ветви (я использую только мастер в качестве имени)

Затем сценарии трубопроводных выглядеть следующим образом MR

checkout ([ 
     $class: 'GitSCM', 
     branches: [[name: "${env.gitlabSourceNamespace}/${env.gitlabSourceBranch}"]], 
     extensions: [ 
     [$class: 'PruneStaleBranch'], 
     [$class: 'CleanCheckout'], 
     [ 
      $class: 'PreBuildMerge', 
      options: [ 
     fastForwardMode: 'NO_FF', 
      mergeRemote: env.gitlabTargetNamespace, 
      mergeTarget: env.gitlabTargetBranch 
      ] 
     ] 
     ], 
     userRemoteConfigs: [ 
     [ 
      name: env.gitlabTargetNamespace, 
      url: env.gitlabTargetRepoSshURL 
     ], 
     [ 
      name: env.gitlabSourceNamespace, 
      url: env.gitlabSourceRepoSshURL 
     ] 
     ] 
     ]) 

мастер

checkout([ 
     $class: 'GitSCM', 
     branches: [[name: '*/master']], 
     extensions: [ 
     [$class: 'PruneStaleBranch'], 
     [$class: 'CleanCheckout']], 
     userRemoteConfigs: [[url: '<my-git-url>']]]) 

Это дает мне два рабочих места. Задача MR зависит от плагина GitLab, чтобы определить, какие источники и целевые репозитории и филиалы проверяются, объединяются и строятся. Мастер-задание будет только строить мастер-репо.

Последний шаг - настроить webhooks в GitLab для репо.Когда вы делаете webhook в GitLab, он запрашивает следующую информацию:

  • Endpoint URL (это находится в работе Дженкинс под Сложение Триггеры раздел)
  • События (соответствуют события из работы Дженкинс в здесь)
  • SSL Проверка (до вас и вашей конфигурации сети)

и вы должны сделать!

 Смежные вопросы

  • Нет связанных вопросов^_^