что я сделал довольно просто:

1. установите плагин задачи Hudson Post
2. Создайте личный маркер доступа здесь:https://github.com/settings/tokens

3. добавить плагин 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!\"
   }"
   

4. добавьте плагин 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!\"
   }"
   

5. вы также можете добавить вызов в ожидание в начале тесты

   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.

Я также предполагаю, что вы уже настроили свою работу Дженкинса, которая будет вызвана веб-крючком или опросом. Вот шаги, которые я предпринял, чтобы заставить его работать:

1. настройка Github: создание личного маркера доступа с областью OAuth repo:status
2. Настроить Дженкинс: Configure System и добавьте секрет OAuth как Сервер GitHub - используйте Secret Text как метод аутентификации, чтобы поместить туда секрет OAuth.
3. настройка задания Дженкинса: добавить Set GitHub commit status as действие после сборки. Установите Результате Статус to One of the default messages and statuses.
4. проверьте результат на GitHub: Проверьте, получаете ли Вы статус сборки и продолжительность выполнения сборки на GitHub совершать.

Настройка Github

настроить Дженкинс!--26-->

Настройка Jenkins Иов

результат

теперь вы увидите статус ваших коммитов и ветвей:

Если у вас Github плагин установлен на вашем Jenkins, вы можете сделать это Post build actions такой :

в отношении настройки защищенной ветви Дженкинса и GitHub. Я использую Jenkins 2.6, и это шаги, которые я сделал, чтобы заставить его работать:

на веб-странице GitHub вашего репозитория:

1. перейдите в раздел Настройки > филиалы.
2. в разделе Защита ветвей нажмите на выберите филиал утопить меню вниз и выберите ветвь установить как защищенную ветвь.
3. включить параметры по мере необходимости.

о Дженкинсе Сервер: (Убедитесь, что у Вас установлен плагин Git и GitHub)

1. перейдите к управлению Jenkins > настройка системы.
2. под гитхаб, набор API и URL-адрес https://api.github.com. Хотя это значение по умолчанию.
3. выберите созданный маркер для учетных данных. Если вы еще не создали токен, нажмите "Дополнительно"... затем при дополнительных действиях вы можете преобразовать свой логин и пароль в токен и использовать его как свой мандатный.

кроме того, убедитесь, что учетная запись 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, результатами тестирования и тестовым покрытием.