Показать текущее состояние сборки Jenkins на репо GitHub
есть ли способ показать статус сборки Jenkins на Github Readme моего проекта.md?
Я использую Jenkins для запуска сборки непрерывной интеграции. После каждой фиксации он гарантирует, что все компилируется, а также выполняет модульные и интеграционные тесты, прежде чем, наконец, создавать документацию и выпускать пакеты.
по-прежнему существует риск непреднамеренного совершения чего-то, что нарушает сборку. Это было бы хорошо для пользователей, посещающих страницу проекта GitHub, чтобы знать текущий мастер находится в этом состоянии.
11 ответов
хорошо, вот как вы можете настроить Jenkins для установки статусов сборки GitHub. Это предполагает, что у вас уже есть Дженкинс с плагином GitHub, настроенным на выполнение сборок при каждом нажатии.
-
перейдите в GitHub, войдите в систему, перейдите в настройки, личные жетоны доступа, нажмите кнопку создать новый маркер.
-
Регистрация РЕПО:статус (Я не уверен, что это необходимо, но я сделал это, и это сработало для меня).
создайте токен, скопируйте его.
убедитесь, что пользователь GitHub, которого вы собираетесь использовать, является сотрудником репозитория (для частных репозиториев) или членом команды с доступом push и pull (для репозиториев организации) к репозиториям, которые вы хотите создать.
перейдите на сервер Jenkins, войдите в систему.
- Управление Дженкинс → Настройка Системы
-
под Веб-Крюк GitHub выберите пусть Дженкинс авто-управление URLs крюк, затем укажите свой GitHub имя пользователя и OAuth token вы попали в Шаг 3.
убедитесь, что он работает с Проверить Учетные Данные. сохранить параметры.
-
найдите работу Дженкинса и добавьте установить статус сборки на GitHub commit к шагам после сборки
что я сделал довольно просто:
- установите плагин задачи Hudson Post
- Создайте личный маркер доступа здесь:https://github.com/settings/tokens
-
добавить плагин Post Task, который всегда ставит успех
curl -XPOST -H "Authorization: token OAUTH TOKEN" https://api.github.com/repos/:organization/:repos/statuses/$(git rev-parse HEAD) -d "{ \"state\": \"success\", \"target_url\": \"${BUILD_URL}\", \"description\": \"The build has succeeded!\" }"
-
добавьте плагин Post Task, который поставит сбой, если "отмечена сборка как сбой"
curl -XPOST -H "Authorization: token OAUTH TOKEN" https://api.github.com/repos/:organization/:repos/statuses/$(git rev-parse HEAD) -d "{ \"state\": \"failure\", \"target_url\": \"${BUILD_URL}\", \"description\": \"The build has failed!\" }"
-
вы также можете добавить вызов в ожидание в начале тесты
curl -XPOST -H "Authorization: token OAUTH TOKEN" https://api.github.com/repos/:organization/:repos/statuses/$(git rev-parse HEAD) -d "{ \"state\": \"pending\", \"target_url\": \"${BUILD_URL}\", \"description\": \"The build is pending!\" }"
этот плагин должен работать:https://wiki.jenkins-ci.org/display/JENKINS/Embeddable + Build + статус + плагин
вы должны иметь возможность вставлять такие значки в свой :
на зафиксировать статус API позволяет увидеть "API статусов РЕПО".
и с 26 апреля 2013 года, теперь вы можете увидеть построить статус на страница филиала GitHub repo:
Это означает, что это другой способ, посетив страницу проекта GitHub, чтобы увидеть эти статусы вместо того, чтобы иметь только Дженкинса.
с 30 апреля 2013 года конечная точка API для фиксации статусы был расширен, чтобы разрешить ветвь и имена тегов, а также фиксация SHAs.
есть также Этот плагин, который даст вам URL-адрес значка, который вы можете опубликовать в своем README.md и выглядит так
https://wiki.jenkins-ci.org/display/JENKINS/Embeddable+Build+Status+Plugin
тем временем пользовательский интерфейс Дженкинса и GitHub немного изменился, и мне потребовалось некоторое время, чтобы понять, как правильно настроить Дженкинса. Объяснение здесь основано на версии Дженкинса 2.121.1.
Я также предполагаю, что вы уже настроили свою работу Дженкинса, которая будет вызвана веб-крючком или опросом. Вот шаги, которые я предпринял, чтобы заставить его работать:
- настройка Github: создание личного маркера доступа с областью OAuth
repo:status
- Настроить Дженкинс:
Configure System
и добавьте секрет OAuth как Сервер GitHub - используйтеSecret Text
как метод аутентификации, чтобы поместить туда секрет OAuth. - настройка задания Дженкинса: добавить
Set GitHub commit status
as действие после сборки. Установите Результате Статус toOne of the default messages and statuses
. - проверьте результат на GitHub: Проверьте, получаете ли Вы статус сборки и продолжительность выполнения сборки на GitHub совершать.
Настройка Github
настроить Дженкинс!--26-->
Настройка Jenkins Иов
результат
теперь вы увидите статус ваших коммитов и ветвей:
Если у вас Github
плагин установлен на вашем Jenkins
, вы можете сделать это Post build actions
такой :
в отношении настройки защищенной ветви Дженкинса и GitHub. Я использую Jenkins 2.6, и это шаги, которые я сделал, чтобы заставить его работать:
на веб-странице GitHub вашего репозитория:
- перейдите в раздел Настройки > филиалы.
- в разделе Защита ветвей нажмите на выберите филиал утопить меню вниз и выберите ветвь установить как защищенную ветвь.
- включить параметры по мере необходимости.
о Дженкинсе Сервер: (Убедитесь, что у Вас установлен плагин Git и GitHub)
- перейдите к управлению Jenkins > настройка системы.
- под гитхаб, набор API и URL-адрес https://api.github.com. Хотя это значение по умолчанию.
- выберите созданный маркер для учетных данных. Если вы еще не создали токен, нажмите "Дополнительно"... затем при дополнительных действиях вы можете преобразовать свой логин и пароль в токен и использовать его как свой мандатный.
кроме того, убедитесь, что учетная запись GitHub, которую использует ваш Дженкинс, является сотрудником репозитория. Я установил его с уровнем разрешения.
надеюсь, что это помогает.
добавить строку ниже в свой README.md и измените оба URL-адреса в соответствии с вашим проектом jenkins.
[![Build Status](https://jenkins../..project/lastBuild/buildStatus)](https://jenkins../..project/lastBuild/)
Jently обновление состояние фиксации Github (как описано @vonc выше), к сожалению, они еще не реализовали API статуса РЕПО
Edit:
Я больше не использую этот подход, пожалуйста, используйте один из других ответов.
Update: что я закончил делать, для нашего конкретного случая: (выше ответы были великолепны - спасибо!)
поскольку наш сервер сборки не находится в интернете, у нас есть скрипт для публикации статуса сборки в ветке gh-pages в github.
- Начало сборки штампов не удается
- конец сборки успех марки
- проект запускается после основного проекта для публикации результатов - > build-status, API docs, test reports и Test coverage.
GitHub кэширует изображения, поэтому мы создали .файл htaccess, который указывает короткий тайм-аут кэша для образа состояния сборки.
поместите это в каталог с изображением состояния сборки:
ExpiresByType image/png "access plus 2 minutes"
здесь сценарий сборки. Цель, которая публикуется на gh-страницах '--опубликовать.сайт.сухой.беги!--11-->
менее 400 строк конфига, мы имеем:
- скомпилировать проверки
- модульные и интеграционные тесты
- Испытаний
- Отчеты О Покрытии Кода
- API Docs
- публикация в Github
. . и этот скрипт можно запустить в Дженкинсе или за его пределами, так что:
- разработчики могут запустите этот скрипт перед фиксацией, уменьшая вероятность сломанной сборки, которая влияет на других.
- сбой легко воспроизвести локально.
Результаты:
главная страница имеет статус сборки, обновляется после каждой сборки, вместе с последними документами API, результатами тестирования и тестовым покрытием.