Чи є спосіб показати статус збірки Дженкінса на GitHub Readme.md мого проекту?

Я використовую Дженкінса для запуску безперервних інтеграційних побудов. Після кожного виконання зобов’язання гарантує, що все компілюється, а також виконує тести для одиниць та інтеграції, перш ніж остаточно виготовити документацію та випустити пакети.

Все ще існує ризик ненавмисного вчинити щось, що порушує збірку. Користувачам, які відвідують сторінку проекту GitHub, було б добре знати, що поточний майстер знаходиться в такому стані.

Ок, ось як можна налаштувати Дженкінс для встановлення статусів GitHub. Це передбачає, що у вас вже є Дженкінс із плагіном GitHub, налаштованим робити побудови на кожному натисканні.

1. Перейдіть на GitHub, увійдіть, перейдіть у Налаштування , Особисті маркери доступу , натисніть Створити новий маркер .

   

2. Перевірте репо: статус (я не впевнений, що це потрібно, але я це зробив, і він працював на мене).

   

3. Створіть маркер, скопіюйте його.

4. Переконайтеся, що користувач GitHub, який ви збираєтеся використовувати, є співпрацею сховища (для приватних репост) або є членом команди, яка має доступ "push and pull" (для репортажів організації) до сховищ, які ви хочете створити.

5. Перейдіть до свого сервера Jenkins, увійдіть.

6. Керуйте Дженкінсом → Налаштування системи

7. У розділі Веб-гачок GitHub виберіть Дозвольте Дженкінсу автоматично керувати URL-адресами гака , а потім вкажіть своє ім'я користувача GitHub та маркер OAuth, який ви отримали на кроці 3.

   

8. Переконайтеся, що він працює за допомогою кнопки Test Credential . Збережіть налаштування.

9. Знайдіть роботу Дженкінса і додайте статусу встановлення збірки на GitHub до виконання кроків після збирання

   

Це воно. Тепер зробіть тестову збірку та перейдіть до сховища GitHub, щоб перевірити, чи працює він. Клацніть на Відділення на головній сторінці сховища, щоб побачити статуси складання.

Ви повинні побачити зелені галочки:

Тим часом користувальницький інтерфейс Дженкінса і GitHub трохи змінився, і мені знадобилося певний час, щоб зрозуміти, як правильно налаштувати Дженкінса. Пояснення тут ґрунтується на версії 2.121.1 Дженкінса.

Я також припускаю, що ви вже налаштували роботу вашого Дженкінса за допомогою веб-камери або опитування. Це кроки, які я вжив, щоб він працював:

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

Налаштуйте Github

Налаштуйте Дженкінса

Налаштуйте роботу Дженкінса

Результат

Тепер ви побачите статус своїх комісій та відділень:

Що я зробив досить просто:

1. Встановіть плагін Hudson Post Task
2. Створіть маркер особистого доступу тут: https://github.com/settings/tokens

3. Додайте плагін для публікації завдань, який завжди матиме успіх

   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. Додайте плагін для публікації завдань, який призведе до відмови, якщо "позначено збірку як збій"

   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+Status+Plugin

Ви повинні мати можливість вставляти такі значки у свій README.mdфайл:

Commit Status API дозволяє побачити « Repo Статуси API ».

А з 26 квітня 2013 року тепер ви можете бачити статус збірки на своїй філії на сторінці GitHub :

Це означає, що це ще один спосіб, відвідавши сторінку проекту GitHub, щоб побачити ці статуси, а не лише Дженкінса.

Починаючи з 30 квітня 2013 року, кінцеву точку API статусів комісій було розширено, щоб дозволити імена гілок та тегів, а також виконувати SHA .

Також є цей плагін, який надасть вам URL-адресу значка, який ви можете розміщувати у своєму README.md і виглядає приблизно так

https://wiki.jenkins-ci.org/display/JENKINS/Embeddable+Build+Status+Plugin

Якщо у вас встановлений Githubплагін Jenkins, ви можете це зробити Post build actionsтак:

Додайте нижній рядок у своєму README.md та змініть обидві URL-адреси відповідно до вашого проекту jenkins.

[![Build Status](https://jenkins../..project/lastBuild/buildStatus)](https://jenkins../..project/lastBuild/)

Що стосується створення Дженкінса та захищеного відділення GitHub. Я використовую Jenkins 2.6, і це кроки, які я зробив для того, щоб він працював:

На веб-сторінці GitHub вашого сховища:

1. Перейдіть до Налаштування> Відділення.
2. У розділі Захист гілок натисніть на меню Вибрати гілку, що випадає, і виберіть гілку, яку потрібно встановити як Захищену гілку.
3. Увімкніть параметри за потребою.

На сервері Jenkins: (Переконайтеся, що у вас встановлені додатки Git та GitHub)

1. Перейдіть до пункту Керування Дженкінсом> Налаштування системи.
2. Під GitHub встановіть URL-адресу API на https://api.github.com . Хоча це значення за замовчуванням.
3. Виберіть свій згенерований маркер для облікових даних. Якщо ви ще не створили маркер, натисніть кнопку Додатково ... потім на Додаткові дії, ви можете перетворити свій логін і пароль в маркер і використовувати його як свою облікову інформацію.

Також переконайтеся, що обліковий запис GitHub, який використовує ваш Дженкінс, є співавтором для сховища. Я встановив його з рівнем дозволу на запис.

Сподіваюся, це допомагає.

Я виконував вказівки від Алекса, і це спрацювало.

Але для GitHub Enterprise вам потрібно змінити URL-адресу API при додаванні сервера до Дженкінса.

Наприклад, якщо ваша компанія - Creditcard.com, ваша URL-адреса буде

https://github.creditcard.com/api/v3/

Терміново оновлює свій статус фіксації Github (як описано вище @vonc), на жаль, вони ще не застосували API статусу Repo

Редагувати:

Я більше не використовую цей підхід, будь ласка, використовуйте одну з інших відповідей.

Оновлення: що я в кінцевому підсумку робив для нашого конкретного випадку: (вище відповіді були чудовими - дякую!)

Оскільки наш сервер збирання відсутній в Інтернеті, у нас є сценарій для публікації статусу збірки у відділенні gh-pages у github.

• Невдача початку створення штампів
• Кінець успіху нарощування марок
• Проект запускається після того, як основний проект опублікує результати -> статус збірки, документи API, звіти про тести та покриття тесту.

GitHub кешує зображення, таким чином ми створили файл .htaccess, який вказує на короткий час очікування кешу для зображення статусу збірки.

Помістіть це в каталог із зображенням статусу збірки:

ExpiresByType image/png "access plus 2 minutes"

Ось сценарій збірки. Ціль, яка публікується на gh-сторінках, - "--publish.site.dry.run"

Маючи менше 400 рядків конфігурації, ми маємо:

• Складіть чеки
• модульні та інтеграційні тести
• Звіти про випробування
• Звіти про покриття коду
• Документи API
• Публікація в Github

. . і цей сценарій можна запускати в Дженкінсі або за його межами, щоб:

• Розробники можуть запускати цей скрипт перед фіксацією, знижуючи ймовірність зламаної збірки, що впливає на інших.
• Відмову легко відтворити локально.

Результати:

Основна сторінка проекту має статус збірки, оновлюється після кожної збірки, а також останні документи Документи API, результати тестів та покриття тесту.