C'è un modo per mostrare lo stato di compilazione di Jenkins sul GitHub Readme.md del mio progetto?

Uso Jenkins per eseguire build di integrazione continua. Dopo ogni commit assicura che tutto sia compilato, oltre a eseguire test unitari e di integrazione, prima di produrre finalmente documentazione e rilasciare bundle.

C'è ancora il rischio di commettere inavvertitamente qualcosa che rompe la build. Sarebbe utile per gli utenti che visitano la pagina del progetto GitHub sapere che l'attuale master è in quello stato.

Ok, ecco come puoi configurare Jenkins per impostare gli stati di build di GitHub. Questo presuppone che tu abbia già Jenkins con il plugin GitHub configurato per fare build su ogni push.

1. Vai su GitHub, accedi, vai su Impostazioni , Token di accesso personale , fai clic su Genera nuovo token .

   

2. Controlla repo: status (non sono sicuro che sia necessario, ma l'ho fatto e ha funzionato per me).

   

3. Generare il token, copiarlo.

4. Assicurarsi che l'utente GitHub che si intende utilizzare sia un collaboratore del repository (per repository privati) o sia un membro di un team con accesso push e pull (per repository dell'organizzazione) ai repository che si desidera creare.

5. Vai al tuo server Jenkins, accedi.

6. Gestisci Jenkins → Configura sistema

7. In GitHub Web Hook seleziona Consenti a Jenkins di gestire automaticamente gli URL hook , quindi specifica il tuo nome utente GitHub e il token OAuth che hai ottenuto nel passaggio 3.

   

8. Verifica che funzioni con il pulsante Test credenziali . Salva le impostazioni.

9. Trova il lavoro Jenkins e aggiungi Imposta stato build su GitHub commit ai passaggi post-build

   

Questo è tutto. Ora fai un build di test e vai al repository GitHub per vedere se ha funzionato. Fare clic su Branches nella pagina principale del repository per visualizzare gli stati di compilazione.

Dovresti vedere segni di spunta verdi:

Nel frattempo l'interfaccia utente di Jenkins e GitHub è cambiata un po 'e mi ci è voluto un po' di tempo per capire come configurare Jenkins ora correttamente. La spiegazione qui è basata sulla versione 2.121.1 di Jenkins.

Suppongo anche che tu abbia già configurato il tuo lavoro Jenkins per essere attivato da un webhook o da polling. Questi sono i passaggi che ho preso per farlo funzionare:

1. Configura Github: Crea token di accesso personale con OAuth Scope repo:status
2. Configura Jenkins: Configure Systeme aggiungi il Segreto OAuth come server GitHub - usa Secret Textcome metodo di autenticazione per inserire il Segreto OAuth.
3. Configura il tuo lavoro Jenkins: aggiungi Set GitHub commit statuscome azione post-build . Impostare il risultato dello stato su One of the default messages and statuses.
4. Controlla il tuo risultato su GitHub: controlla se ottieni lo stato e la durata dell'esecuzione del build sul tuo commit GitHub.

Configura Github

Configura Jenkins

Configura Jenkins Job

Risultato

Ora vedrai lo stato dei tuoi commit e filiali:

Quello che ho fatto è abbastanza semplice:

1. Installa il plug-in Hudson Post Task
2. Crea un token di accesso personale qui: https://github.com/settings/tokens

3. Aggiungi un plug-in Post Task che abbia sempre avuto successo

   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. Aggiungi un plug-in Post Task che metterà l'errore se "contrassegna build come errore"

   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. È inoltre possibile aggiungere una chiamata a in sospeso all'inizio dei test

   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!\"
   }"
   

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

Dovresti essere in grado di incorporare badge come questo nel tuo README.mdfile:

L' API di stato Commit ti consente di visualizzare l' API " Repo Statuses ".

E dal 26 aprile 2013, ora puoi vedere lo stato della build nella pagina della tua filiale repository GitHub :

Ciò significa che è un altro modo, visitando la pagina del progetto GitHub, vedere quegli stati invece di avere solo Jenkins.

A partire dal 30 aprile 2013, l' endpoint API per gli stati di commit è stato esteso per consentire nomi di filiali e tag, nonché SHA di commit .

C'è anche questo plugin che ti darà un URL distintivo che puoi pubblicare nel tuo README.md e assomiglia a questo

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

Se hai Githubinstallato un plugin sul tuo Jenkins, puoi farlo in Post build actionsquesto modo:

Aggiungi sotto la riga nel tuo README.md e modifica entrambi gli URL in base al tuo progetto jenkins.

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

Per quanto riguarda la creazione del ramo protetto di Jenkins e GitHub. Sto usando Jenkins 2.6 e questi sono i passaggi che ho fatto per farlo funzionare:

Sulla pagina Web GitHub del repository:

1. Passare a Impostazioni> Filiali.
2. In Proteggi rami, fai clic sul menu a discesa Scegli un ramo e seleziona il ramo che desideri impostare come ramo protetto.
3. Abilita le opzioni secondo necessità.

Sul server Jenkins: (assicurati di avere installato il plugin Git e GitHub)

1. Passare a Gestisci Jenkins> Configura sistema.
2. Sotto GitHub, imposta l'URL dell'API su https://api.github.com . Sebbene questo sia il valore predefinito.
3. Seleziona il token generato per le credenziali. Se non hai ancora generato un token, fai clic su Avanzate ... quindi su Ulteriori azioni, puoi convertire il tuo login e password in token e usarlo come credenziale.

Inoltre, assicurati che l'account GitHub utilizzato da Jenkins sia un collaboratore per il repository. L'ho impostato con il livello di autorizzazione in scrittura.

Spero che questo ti aiuti.

Ho seguito le indicazioni di Alex e ha funzionato.

Tuttavia, per GitHub Enterprise è necessario modificare l'URL dell'API quando si aggiunge il server a Jenkins.

Ad esempio, se la tua azienda è creditcard.com, il tuo URL lo sarebbe

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

Aggiorna jently il tuo stato di commit di Github (come descritto da @vonc sopra), sfortunatamente devono ancora implementare l' API di stato di Repo

Modificare:

Non sto più usando questo approccio, per favore usa una delle altre risposte.

Aggiornamento: quello che ho finito per fare, per il nostro caso specifico: (le risposte sopra sono state fantastiche - grazie!)

Poiché il nostro server di build non è su Internet, abbiamo uno script per pubblicare lo stato di build nel ramo gh-pages in github.

• Inizio dei timbri di costruzione non riusciti
• Successo di timbri di fine costruzione
• Il progetto viene eseguito dopo il progetto principale per pubblicare i risultati -> stato build, documenti API, rapporti sui test e copertura dei test.

GitHub memorizza nella cache le immagini, quindi abbiamo creato il file .htaccess, che indica un breve timeout della cache per l'immagine di stato della build.

Inseriscilo nella directory con l'immagine di stato build:

ExpiresByType image/png "access plus 2 minutes"

Ecco lo script di compilazione. Il target che pubblica su gh-pages è '--publish.site.dry.run'

Con meno di 400 linee di configurazione, abbiamo:

• Compilare i controlli
• test di unità e integrazione
• Rapporti di prova
• Rapporti sulla copertura del codice
• Documenti API
• Pubblicazione su Github

. . e questo script può essere eseguito all'interno o all'esterno di Jenkins, in modo che:

• Gli sviluppatori possono eseguire questo script prima di eseguire il commit, riducendo la possibilità di una build interrotta che influisce sugli altri.
• Un errore è facile da riprodurre localmente.

I risultati:

La pagina principale del progetto ha lo stato della build, aggiornato dopo ogni build, insieme agli ultimi documenti API, ai risultati dei test e alla copertura dei test.