Come posso fare in modo che Jenkins CI con Git si attivi sui push al master?

Sto cercando di configurare Jenkins-ci per un progetto usando GitHub. Ho già configurato Jenkins con i plugin appropriati. Voglio che Jenkins esegua script di compilazione solo ogni volta che qualcuno nel progetto spinge a padroneggiare. Finora sono stato in grado di configurarlo in modo che una build venga attivata ogni volta che qualcuno spinge ovunque, ma è troppo ampio. L'ho fatto con gli hook di servizio post-ricezione su Git.

Ho letto il wiki di Jenkins e un paio di tutorial, ma manca questo particolare dettaglio ... forse ha a che fare con il sondaggio? O dovrebbe essere fatto il lavoro sul lato Git, in modo che Git inneschi Jenkins solo quando masterviene cambiato?

Come già notato da gezzed nel suo commento, nel frattempo c'è una buona soluzione (descritta in Polling deve morire: innescare le build di Jenkins da un hook Git ):

• Impostare il trigger di creazione del lavoro Jenkins su Poll SCM , ma non specificare una pianificazione.

• Crea un trigger post-ricezione GitHub per notificare l'URL

  http://yourserver/jenkins/git/notifyCommit?url=<URL of the Git repository>?token=<get token from git to build remotely>
  

• Ciò attiverà tutte le build che eseguono il polling del repository Git specificato.

• Tuttavia, il polling in realtà controlla se qualcosa è stato inviato al ramo usato.

Funziona perfettamente.

A partire dalla versione 0.5, il plug-in GitHub per Jenkins può attivare una build quando una modifica viene inviata a GitHub .

Invece di attivare le build in remoto, modificare la configurazione del progetto Jenkins per attivare le build tramite polling.

Jenkins può eseguire il polling in base a un interno fisso o tramite un URL. Quest'ultimo è ciò che vuoi saltare le build se non ci sono modifiche per quel ramo. I dettagli esatti sono nella documentazione . In sostanza, devi solo selezionare l'opzione "Poll SCM", lasciare vuota la sezione della pianificazione e impostare un URL remoto per colpire JENKINS_URL / lavoro / nome / polling.

Un gotcha se hai un ambiente Jenkins protetto è diverso /build, l' /pollingURL richiede l'autenticazione. Le istruzioni qui hanno dettagli. Ad esempio, ho un hook di GitHub Post-Ricevi in ​​corso username:apiToken@JENKIS_URL/job/name/polling.

Per GitLab , attenersi alla seguente procedura:

1. Vai alle impostazioni del tuo progetto → Web hook

2. Inserisci l'URL "Build Now" dal tuo progetto Jenkins come URL di un evento push:

   http://server.com/jenkins/job/project_name/build?delay=0sec per esempio

3. Clicca Add Web Hooke poitest hook

Quindi, ogni volta che ti impegni nel repository, viene attivato l'hook web e viene creata una build. Assicurati di impostare l'area di lavoro di Jenkins in delete workspace before each buildmodo da ottenere una nuova copia del nuovo codice.

Non correlato a Git, ma di seguito ti aiuterò con la configurazione del lavoro Jenkins in dettaglio con Mercurial. Può aiutare gli altri con un problema simile.

1. Installa il plug-in Trigger URL
2. Vai alla pagina di configurazione del lavoro e seleziona l' Poll SCMopzione. Impostare il valore su* * * * *
3. Selezionare l'opzione: [URLTrigger] - Poll with a URL. Ora puoi selezionare alcune opzioni come la modifica della data di modifica, il contenuto dell'URL, ecc.
4. Nelle opzioni, seleziona Modifica contenuto URL, seleziona prima opzione - Monitor change of content
5. Salva le modifiche.

Ora, attiva alcune modifiche al repository Mercurial mediante alcuni check-in di test.

Verifica che il lavoro Jenkins ora venga eseguito rilevando le modifiche SCM. Quando la build viene eseguita a causa delle modifiche di Mercurial, verrà visualizzato il testo Started by an SCM change. Altrimenti, l'utente che lo ha avviato manualmente.

Spero che questo aiuti: come attivare una build Jenkins su Git commit

Si tratta solo di usare l'arricciatura per innescare un lavoro Jenkins usando i ganci Git forniti da Git.

Il comando curl http://localhost:8080/job/someJob/build?delay=0secpuò eseguire un lavoro Jenkins, dove someJobè il nome del lavoro Jenkins.

Cerca la cartella "hook" nella cartella nascosta .git. Rinominare il file "post-commit.sample" in "post-commit". Aprilo con Blocco note, rimuovi la riga ": Nothing" e incolla il comando sopra.

Questo è tutto. Ogni volta che esegui un commit, Git attiverà i comandi post-commit definiti nel file.

Integrazione continua con Jenkins, dopo che il codice è stato inviato al repository dal comando / GUI di Git:

1. Crea un lavoro in Jenkins con solo il nome del lavoro e seleziona il tipo di freestyle del progetto. Fare clic OK. La pagina successiva non aggiunge nulla, basta fare clic Save.
2. Vai al repository Git locale in cui hai il codice sorgente e vai alla .git/hookscartella.

3. La hookscartella contiene pochi file. Controlla il "post-commit". Se non presente, crea un file "post-commit" senza estensione:

   C:\work\test\\.git\hooks\post-commit
   

4. Modifica il file "post-commit" con il comando seguente. Assicurarsi che sia presente nella cartella dei hook del codice sorgente locale.

   curl -u userName:apiToken -X POST http://localhost:8080/jenkins/job/jobName/build?token=apiToken
   

   Esempio:

   curl -u admin:f1c55b3a07bb2b69b9dd549e96898384 -X POST http://localhost:8080/jenkins/job/Gitcommittest/build?token=f1c55b3a07bb2b69b9dd549e96898384
   

   5.

   userName: Nome utente Jenkins

   jobName: Nome lavoro della build

   apiToken: Per ottenere il token API, vai alla tua pagina utente Jenkins (in alto a destra nell'interfaccia). È disponibile nel menu "Configura" a sinistra della pagina: "Mostra token API"

5. Apporta le modifiche al codice sorgente e invia il codice al repository.

6. Il tuo lavoro, http://localhost:8080/jenkins/job/Gitcommittest/dovrebbe essere la costruzione.

Devi specificare il ramo. Di default ascolta qualsiasi cosa. Vedi il post sul blog Hudson: plugin Git e Maven .

Plugin di trigger Webhook generico possibile configurare il con filtri.

Se configurato con

• Una variabile denominata refed espressione$.ref .
• Un filtro con testo $refed espressione del filtro simile ^refs/heads/master$.

Quindi quel lavoro si attiverà per ogni spinta verso master . Nessun polling.

Probabilmente vuoi più valori dal webhook per eseguire effettivamente la build. Basta aggiungere più variabili, con JSONPath, per scegliere ciò di cui hai bisogno.

Ci sono alcuni casi d'uso qui: https://github.com/jenkinsci/generic-webhook-trigger-plugin/tree/master/src/test/resources/org/jenkinsci/plugins/gwt/bdd

Nella mia attuale organizzazione, non lo facciamo in master ma lo facciamo sia in sviluppo che in rilascio / rami (stiamo usando Git Flow), al fine di generare build di istantanee.

Poiché stiamo usando una pipeline multi-ramo, lo facciamo nel file Jenkins con la sintassi when {} ...

stage {
    when { 
        expression { 
            branch 'develop'
        }
    }
}

Questo è dettagliato in questo post del blog: https://jenkins.io/blog/2017/01/19/converting-conditional-to-pipeline/#longer-pipeline

Le risposte sopra sono corrette, ma mi rivolgo a coloro che sono principianti qui per la loro semplicità

soprattutto per l'impostazione del trigger di generazione per la pipeline:

Considera di avere due rami Github: 1.master, 2.dev e Jenkinsfile (dove è scritto lo script della pipeline) e altri file sono disponibili su ogni ramo

Configura nuovo progetto Pipeline (per ramo dev)

## 1.Integrazione del codice con git-plugin e approccio basato su cron Il plug-in git prerequisito deve essere installato e configurarlo con il tuo nome ed e-mail

1. Sezione generale Seleziona la casella di controllo - "Questo progetto è parametrizzato" e aggiungi Nome-SBRANCH Valore predefinito-'refs / remotes / origin / dev '
2. Crea sezione trigger "Seleziona la casella di controllo -" Poll SCM "e programma secondo necessità per il controllo, ad esempio" * / 1 * * * * "per controllare ogni minuto
3. Sezione definizione pipeline.Seleziona - Script pipeline da SCM—> seleziona git—> addRepository URL—> aggiungi credenziali git—> scegli avanzato—> aggiungi Name- origin, RefSpec- '+ refs / heads / dev: refs / remotes / origin / dev '(dev is github branch) -> Branches da costruire - $ {SBRANCH} (Nome parametro dal primo punto di riferimento) -> Percorso script—> Jenkinsfile -> Deseleziona Lightweightcheckout
4. Applica—> salva

## 2. Integrazione del codice: approccio github-plugin e webhook Prerequisito Il plug-in Github deve essere installato e il server Github deve essere configurato, la connessione deve essere testata se non si considera la seguente configurazione

Configura plugin Github con account su Jenkins

Sezione GitHub Aggiungi server Github se non presente URL API: https://api.github.com Credenziali: Aggiungi testo segreto (fai clic sul pulsante Aggiungi: seleziona il tipo di testo segreto) con valore Token di accesso personale (generalo dai tuoi account Github—> impostazioni -> impostazione sviluppatore—> token di accesso personale—> aggiungi token—> controlla gli ambiti—> copia il token) Test connessione—> Controlla se è collegato al tuo account Github o no Seleziona la casella di controllo con Gestisci ganci Nella sottosezione in anticipo basta selezionare credenziali precedenti per "segreto condiviso"

Aggiungi webhook se non aggiunto al tuo repository da

1. Vai alle impostazioni del repository Github -> aggiungi webhook—> aggiungi URL
   http: // Public_IP: Jenkins_PORT / github-webhook /
2. O se non hai Public_IP usa ngrok . Installa, autentica, ottieni l'IP pubblico dal comando ./ngrok http 80 (usa il tuo jenkins_port) quindi aggiungi webhook -> aggiungi URL http: // Ngrok_IP / github-webhook /
3. Provalo consegnando payload dalla pagina webhook e controlla se ottieni 200 stati o meno.

Se si dispone del plug-in di richieste Github Pull, configurarlo anche con l'URL Jenkins pubblicato.

1. Sezione generale Seleziona la casella di controllo - 'Progetto Github' aggiungi l'URL del progetto - (collegamento github che termina con '.git /')
2. Sezione generale Seleziona la casella di controllo - "Questo progetto è parametrizzato" e aggiungi Nome-SBRANCH Valore predefinito-'refs / remotes / origin / dev '
3. Build triggers.section.Check checkbox - 'Trigger hook GitHub per polling GITScm'
4. Pipeline def'n section: Select - Pipeline script from SCM—> select git—> addRepository URL—> aggiungi credenziali git—> scegli avanzato -> aggiungi Name- origin, RefSpec- '+ refs / heads / dev: refs / remotes / origin / dev '(dev is github branch) -> Branches da costruire - $ {SBRANCH} (nome del parametro dal punto 1.st di riferimento) -> Percorso script—> Jenkinsfile—> Deseleziona Lightweightcheckout
5. Applica—> salva

Utilizza il plug-in del builder request request: https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin

È davvero semplice. È quindi possibile configurare i webhook di GitHub per attivare build.

La mia soluzione per un server git locale: vai alla directory hook del tuo server git locale, ignora il update.sample esistente e crea un nuovo file chiamato letteralmente come "update", come:

gituser@me:~/project.git/hooks$ pwd
/home/gituser/project.git/hooks
gituser@me:~/project.git/hooks$ cat update
#!/bin/sh
echo "XXX from  update file"
curl -u admin:11f778f9f2c4d1e237d60f479974e3dae9 -X POST http://localhost:8080/job/job4_pullsrc_buildcontainer/build?token=11f778f9f2c4d1e237d60f479974e3dae9

exit 0
gituser@me:~/project.git/hooks$ 

L'istruzione echo verrà visualizzata sotto il risultato git push, il token può essere preso dalla configurazione del lavoro jenkins, sfogliare per trovarlo. Se il file "update" non viene chiamato, provare alcuni altri file con lo stesso nome senza estensione "sample".

Questo è tutto ciò di cui hai bisogno