GitHub и Jenkins проверяют запросы

В моем предыдущем посте, озаглавленном « Интеграция GitHub и Jenkins», я показал один из возможных способов интеграции GitHub с Jenkins и обрисовал идею и последовательность проверки запросов по запросу. В этой статье я покажу вам, как настроить работу Jenkins для достижения этой цели, а также как добавить немного фантазии во весь этот процесс.

Настройка работы Дженкинс

Взявшись за то, что я оставил, давайте создадим простую работу Дженкинса, чтобы продемонстрировать всю идею проверки запросов. Так как в определении задания Jenkins может появиться много вещей, давайте сосредоточимся на том, что требуется для этой интеграции, и оставим все остальное. Первое, что вам нужно сделать, это предоставить ссылку на ваш репозиторий GitHub в поле проекта GitHub. URL соответствует установленному соглашению GitHub (и будет использоваться в других местах этой конфигурации) https://GITHUB_HOST:GITHUB_PORT/ORGANISATION/REPOSITORY . Это поле находится в верхней части страницы конфигурации задания.

Далее сосредоточимся на разделе «Управление исходным кодом» конфигурации. Выбрав Git, вы можете начать с выбора учетных данных и спецификации URL репозитория. Если вы следовали моему совету из предыдущего поста, просто введите учетные данные, которые принадлежат пользователю, созданному специально для целей автоматизации. URL должен указывать на файл проекта .git, а его схема немного отличается от вышеупомянутого URL проекта, поэтому не git@GITHUB_HOST:GITHUB_PORT/ORGANISATION/REPOSITORY.git их с git@GITHUB_HOST:GITHUB_PORT/ORGANISATION/REPOSITORY.git .

После нажатия на Advanced вам будут предложены некоторые дополнительные характеристики для заполнения. Это важная часть, поскольку она определяет, что проверяется во время выполнения задания. Имя ветви должно быть установлено в origin а выражение refspec должно быть введено следующим образом: +refs/pull/*:refs/remotes/origin/pr/* . Последнее, что нужно указать, — это спецификатор ветви и выберите предпочитаемый браузер репозитория. Спецификатор ветви имеет значение, предоставленное GitHub, доступное через параметр сборки ${sha1} .

Последний шаг этой конфигурации — настроить поведение плагина GitHub Pull Request Builder . Перейдите в раздел «Построение триггеров» и убедитесь, что единственным отмеченным параметром из списка является GitHub Pull Request Builder. Не забудьте установить флажок Использовать перехватчики github для запуска сборки, чтобы плагин правильно собирал события, отправленные с GitHub.

И это все для интеграции GitHub и Jenkins. На этом этапе вы можете идти, так как настройки по умолчанию работают достаточно хорошо. Если вы работаете с локальным экземпляром GitHub, вы можете рассмотреть возможность автоматической проверки каждого запроса на сборку без запроса (Опасно!) В разделе «Дополнительно». Эта опция может быть опасна для публичной версии, поскольку она позволяет любому запускать свой код. В случае, если вы используете локальный экземпляр GitHub, он делает проверки запросов по запросу мгновенными, делая результаты доступными в кратчайшие возможные сроки без необходимости одобрения администраторов.

Как это выглядит, когда он работает?

Ну, это, конечно, справедливый вопрос, особенно после всей этой работы по настройке. То, как эта интеграция разработана, делает GitHub интерфейсом, а Jenkins — интерфейсом всего решения. Что имеет смысл, учитывая их соответствующие роли и возможности. Сказав это, давайте сосредоточимся на представлении GitHubs различных состояний работы сборки и на то, как это выглядит.

Пользовательский интерфейс и UX этой интеграции очень минималистичны по своей природе (и звучит более модно, я осмелюсь назвать это «скейоморфным») и прекрасно вписываются в весь пользовательский интерфейс GitHub и рабочий процесс. Рассмотрим следующую фотографию, сделанную из списка запросов на извлечение:

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

Этот раздел не только расширяет исходное поле кнопок слияния, предоставляя информацию о результате задания сборки, но также связывает само задание сборки.

Следует помнить одну вещь: всегда убедитесь, что вы можете автоматически объединить код, который вы нажимаете, при создании запроса на извлечение . Этот процесс довольно прост и не может угадать, как бы вы хотели разрешить конфликты слияния. Извлечение последней версии кода и ручное разрешение конфликтов в вашем коде позволяет откатиться назад и быть уверенным, что задание на сборку протестирует ваш код должным образом. Я не уверен, что на самом деле создается в случае конфликтов в объединенном коде, и я не хочу знать. Имеет смысл сделать этот шаг частью вашего рабочего процесса независимо от этой интеграции, поэтому я не буду подробно останавливаться на этом.

Построить триггеры

Когда речь идет о способах запуска этого механизма обеспечения качества, у вас есть три варианта:

• Создать новый пул-запрос (через GitHub)
• Внесение новых изменений в существующий запрос на извлечение (через git)
• Используя ручной триггер
  • Это хорошая функция, позволяющая вам выбрать пользовательскую фразу (с возможностью сопоставления с регулярным выражением), которую вы можете использовать, чтобы прокомментировать запрос на получение, что приведет к запланированной сборке Jenkins. Эта опция присутствует в разделе плагинов GitHub PullRequest Builder конфигурации системы Jenkins.

Дальнейшая настройка

Как только у нас будет простая сборка и запуск, мы можем начать думать о дальнейшей настройке этого процесса. Даже если вы можете сделать довольно много в этой области, я бы предложил придерживаться простых решений, где это возможно. Однако это не всегда так, поэтому давайте представим некоторые базовые параметры настройки, которые мы можем использовать в случае, если наша настройка CI требует более сложного решения, чем простая задача сборки:

• Построить параметризацию
• Условные шаги сборки
• Сценарии и API

Построить параметризацию

Всякий раз, когда в GitHub происходит что-то интересное, интеграция на основе плагинов, которую мы настроили в предыдущем посте, сообщит Jenkins. Можно ожидать, что эта интеграция обрабатывается механизмом GitHubs Web Hook. Одно из этих интересных событий, о которых я говорю, безусловно, событие pullrequestevent . Однако, если вы посмотрите на полезную нагрузку указанного события, вам придется некоторое время прокрутить, чтобы увидеть его во всей красе. К счастью, плагин GitHub Pull Request Builder отфильтровывает многие из этих свойств, чтобы сделать информацию, предоставляемую веб-хуками, более доступной и удобной для навигации.

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

Если вам интересно, что находится в вашем распоряжении, проверьте следующий список с примерами параметров сборки:

Условные шаги сборки

Одним из замечательных применений параметризации сборки является использование этапов условной сборки. Типичная ситуация, когда вы хотите применить разные тестовые ghprbTargetBranch на основе целевой ветви (параметр сборки ghprbTargetBranch ). Поработав с этим некоторое время, я в итоге использовал следующую настройку, основанную на том, какая ветвь является целевой ветвью в запросе pull:

• feature ветвь
  • запускать юнит-тесты и анализ качества кода
    • Это тот случай, когда вы закончили с подзадачей данной функции. Область применения относительно мала и проста в модульном тестировании. Поскольку вы, возможно, работаете над функцией с некоторыми из своих товарищей по команде, имеет смысл провести хотя бы модульные тесты, чтобы убедиться, что вы ничего не сломали, а также проверить качество кода (поскольку есть вероятность, что вы не будете беспокоиться о это дальше по дороге).
• develop филиал
  • запускать юнит-тесты, интеграционные и приемочные тесты
    • В этом случае вы закончите со всей функцией, и она должна быть готова к производству. Область применения значительно изменилась, и требуется полный тестовый запуск. Несмотря на то, что существует больше типов тестов, я бы предложил выполнить хотя бы эти три типа, чтобы получить некоторую степень уверенности. На этом этапе код не требует проверки качества, поскольку это было сделано на предыдущем этапе для каждой задачи, переданной в ветвь feature . Мне кажется, что момент, когда эта проверка успешно пройдена, является подходящим временем для отправки этого запроса на проверку кода вашим коллегам.
• master ветка
  • выполнить все проверки
    • Последний шаг — выбрать те черты, которые вы хотите master . Это пресловутая последняя линия защиты для команды разработчиков. Поскольку проверки на уровне ветки develop касаются только того, как данная функция вписывается в последнюю версию ветки develop может возникнуть ситуация, когда две отдельные функции проходят свои индивидуальные проверки запросов на извлечение и все же могут конфликтовать друг с другом, когда оба присутствуют в ветке develop , На этом этапе имеет смысл выполнить все проверки еще раз, чтобы убедиться, что эта ситуация обнаружена и устранена перед выпуском кода. При желании этот шаг можно отразить на ночной работе, выполняемой в ветке develop чтобы сделать процесс выпуска более плавным.

Условная функциональность шага сборки обеспечивается плагином Conditional BuildStep .

Сценарии и API

Последний вариант настройки, который стоит обязательно проверить, это собственный API GitHubs и возможность вызывать его у Дженкинса. Исходя из моего собственного опыта, комментарии и ярлыки являются отличными инструментами, предоставляемыми GitHub для поддержки и управления процессом разработки. Это становится полезным в ситуации, когда работа по сборке занимает много времени или вы хотите улучшить процесс проверки кода.

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

Аргументы сценария:

1. ghprbPullId — идентификатор запроса извлечения
2. комментарий будет добавлен

Что касается процесса проверки кода, мой опыт показывает, что более эффективно разрешить Jenkins проверять код перед отправкой для проверки кода. Это позволяет рецензентам сосредоточиться на бизнес-логике, поскольку синтаксис, форматирование и стиль были проверены Дженкинсом ранее. Поскольку эта информация должна быть доступна из списка запросов на извлечение, я настоятельно рекомендую использовать метки GitHubs в этом сценарии, поскольку они предоставляют хороший способ категоризации материала и легко узнаваемы. Сценарий для назначения такой метки может быть таким простым:

Аргументы сценария:

1. ghprbPullId — идентификатор запроса извлечения
2. ярлык для добавления

Эти сценарии действительно просты в использовании и позволяют предоставлять полезную информацию пользователям GitHub. Вы можете пойти еще дальше и сделать свой комментарий еще более модным. Добавьте некоторые визуальные эффекты или свяжите свои журналы и отчеты о тестах. Ниже приведен простой пример того, как это может выглядеть, если вы готовы немного поиграть с ним:

Вывод

Учитывая все обстоятельства, было довольно весело играть с этими системами. Обе эти системы значительно упрощают жизнь разработчиков, и это небольшое улучшение делает вещи еще более удобными. Когда дело доходит до результатов этой интеграции, они были довольно заметными моментами после развертывания и запуска окончательной версии этого на моем рабочем месте. Если у вас есть эти инструменты, я советую вам попробовать что-то подобное и посмотреть, подходит ли это вашей команде точно так же. Всего наилучшего! 🙂