Как заставить ветки функций git работать с jenkins-workflow?

Я пытаюсь настроить рабочий процесс jenkins для выполнения наших интеграционных тестов. Наши интеграционные тесты работают следующим образом:

Кто-то вносит изменения в LibraryA в функциональной ветке git. Мы хотели бы, чтобы jenkins запускал модульные тесты для кода в функциональной ветке, затем мы хотели бы установить код из этой функциональной ветки в client1 и client2 (которые являются пользователями LibraryA) и запускать их тесты.

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

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

Моя установка выглядит так:

currentBuild.setDisplayName("#" + env.BUILD_NUMBER)

node {
  git credentialsId: '033df7f1-7752-46bd-903d-8a70e613eed0', url: '[email protected]:mycompany/myrepo.git'
  sh '''
echo `git rev-parse HEAD` > libraryA_version.txt
sudo docker run --rm=true -e LANG=en_US.UTF-8 -a stdout -i -t mycompany/libraryA run_tests
'''
  archive 'libraryA_version.txt'
}

def integration_jobs = [:]

integration_jobs[0]={
  node{
    ws {
      unarchive mapping: ['libraryA_version.txt':'.']
      sh 'sudo docker run -t --rm mycompany/client1:v1 bash run_tests.sh "`cat libraryA_version.txt`"'
    }
  }
}

integration_jobs[1] = {
  node{
    ws {
      unarchive mapping: ['libraryA_version.txt' : '.']
      sh 'sudo docker run -t --rm mycompany/client2 run_tests.sh "`cat libraryA_version.txt`" '
    }
  }
}

parallel integration_jobs

Итак, мой текущий вопрос заключается в том, как настроить репозиторий/опрос git, чтобы получить правильный коммит для запуска в первом тесте, который будет использоваться в libraryA_version.txt в последующих тестах?

В качестве альтернативы, должен ли я пройти этот процесс совершенно по-другому?


person Robert    schedule 10.07.2015    source источник


Ответы (2)


Как намекнул @maybeg, вы, скорее всего, ищете многоветвевой проект, доступный после установки Pipeline: Multibranch. Это позволяет вам определить скрипт в Jenkinsfile, который просто вызывает checkout scm один или несколько раз в вашей сборке, избегая необходимости в libraryA_version.txt.

А пока меня интересует настройка вашего проекта. В вашем шаге git используется значение по умолчанию branch: 'master', что означает, что для начала следует опрашивать только ветвь master и проверять только эту ветвь. Плагин Git довольно сложен, поэтому, возможно, он как-то не работает. В ожидании надлежащей поддержки нескольких веток вы всегда можете использовать шаг checkout с GitSCM, настроенным на использование спецификации ветки с подстановочными знаками, и в этом случае для проверки будет выбрана произвольная головка ветки, не созданная ранее, и ваш трюк git-rev-parse (я думаю, вы самостоятельно заново открыли обходной путь для JENKINS-26100) должен работать как есть.

person Jesse Glick    schedule 21.07.2015
comment
Итак, чтобы отразить это, в задании рабочего процесса настройте опрос scm для запуска задания при выполнении фиксации, а затем используйте шаг checkout с подстановочной ветвью (**). Он выберет ветку с головой, которая не была построена, в идеале ветку фиксации, которая инициировала задание? - person Robert; 23.07.2015
comment
Верно, нет никакой гарантии, что выбранная головная фиксация будет причиной триггера, но это вероятно. Навскидку не уверен, что произойдет, если в одном сеансе опроса будет обнаружено несколько подходящих головок — это может вызвать несколько сборок, хотя всякий раз, когда используется опрос SCM (включая веб-перехватчик /git/notifyCommit), целесообразно добавить @daily/@hourly в расписание, чтобы поймать любую случайную ошибку. совершает. Опять же, при использовании предстоящего многоветвевого рабочего процесса все становится проще: каждая ветвь получает свой собственный подпроект, а нотация checkout scm может использоваться ≥1 раз для получения совпадающих проверок. - person Jesse Glick; 24.07.2015
comment
Я смог использовать номенклатуру branch: "production" с новым плагином работы Pipeline под Jenkins ver. 1.634. - person MarkHu; 22.03.2016

Функция, которую вы ищете, — это Build-Per-Branch, и, на мой взгляд, она должна быть реализована соответствующим образом с помощью соответствующих плагинов.

  • Ветвление делается в git.

  • Дженкинс должен скопировать задание сборки или конвейера сборки, чтобы оно соответствовало ветке и имело возможность создавать и тестировать ветку.

  • После реинтеграции git должен сообщить Дженкинсу, а Дженкинс должен закрыть задания.

Я нашел этот плагин:

https://wiki.jenkins-ci.org/display/JENKINS/Multi-Branch+Project+Plugin

И этот плагин/учебник:

http://entagen.github.io/jenkins-build-per-branch/

Реализация сильно зависит от вашего сценария, поэтому я не могу быть более конкретным. Я просто говорю, что проблемы:

  • Создание заданий Jenkins, которые могут выполняться одновременно и независимо.

  • Работа с шаблонами для заданий Jenkins.

  • Обработка событий между Jenkins и git.

В твоем случае:

  • Постройте весь процесс как конвейер доставки от начала до конца.

  • Если кто-то разветвляет шаг и реализует функцию, скопируйте весь конвейер и запустите весь конвейер.

  • Заставьте это работать, а затем улучшите.

person blacklabelops    schedule 11.07.2015
comment
Вот чего я боялся. Вот как мы начали. У нас есть многофункциональная цепочка инструментов, которая работает, но имеет нежелательные качества. Он не масштабируется с нашими репозиториями в том смысле, что у нас слишком много заданий для управления. Уведомления о сбоях и виновники не работают. Настройка через рабочие места является громоздкой. Вот почему плагин jenkins-workflow удобен — настройка всей цепочки интеграции выполняется в одном довольно компактном задании. - person Robert; 13.07.2015
comment
Затем давайте ответим на ваш первоначальный вопрос, вот список переменных среды задания jenkins: wiki.jenkins-ci.org/display/JENKINS/Building+a+software+project. В вашем случае GIT_COMMIT и GIT_BRANCH должны быть информацией, которую вы ищете при построении рабочего процесса. - person blacklabelops; 13.07.2015
comment
Я распечатываю свои env vars вверху задания, и они недоступны. По-видимому, задание jenkins-workflow не устанавливает эти переменные GIT. Следующие переменные в настоящее время недоступны внутри сценария рабочего процесса: EXECUTOR_NUMBER NODE_NAME NODE_LABELS WORKSPACE Переменные, специфичные для SCM, такие как SVN_REVISION - person Robert; 14.07.2015
comment
Похоже, мы застряли с jenkins-workflow. Другое возможное решение — отказаться от git/branches/commits и заглянуть в репозиторий артефактов. Не каждый раз, когда происходит коммит, его следует проверять и создавать, но каждый раз, когда артефакт с меткой xy развертывается заданием ci, его следует помещать в контейнер и тестировать. Посмотрите здесь: wiki.jenkins-ci.org/display/JENKINS/FSTrigger+Plugin - person blacklabelops; 14.07.2015