C'è un modo per separare i webhook di GitHub in tre categorie: master, pull-request e quant'altro?

Question

Quello che sto cercando di realizzare è la seguente Jenkins configurazione (http://jenkins-ci.org) lavoro:

1. avere una serie di <project>-master posti di lavoro ci sono scatenate da

   • Una spinta al ramo principale di quel particolare progetto.
   • Manualmente, facendo clic su "Crea ora"
   • Da uno script che utilizza l'API REST.

   Ho fatto questo specificando refspec appropriato, aggiunto il webhook GitHub, ecc. Era abbastanza semplice.

2. avere una serie di posti di lavoro <project>-pr vengono attivati ​​da

   • Una creazione GitHub PR.
   • Un commento al PR che attiva GitHub Pull Request Builder.
   • Una spinta al ramo che è stato utilizzato per particolari PR.

   Ho fatto fare a Jenkins i primi due. Ma non ho trovato il modo di fare l'articolo # 3 da questo elenco perché i plugin GitHub non riescono a trovare facilmente se il push è in un ramo PR o meno. Qualche idea su come può essere fatto?

3. Avere una serie di lavori <project>-branch attivati ​​da QUALSIASI push su QUALSIASI succursale. Il problema è che voglio escludere i push da master e i rami che vengono utilizzati per le pubbliche relazioni. Ho cercato su Internet una possibile soluzione per giorni e non ho trovato nulla, quindi qualsiasi suggerimento sarà molto apprezzato.

Answer 1

1. Per un posto di lavoro deve essere attivato solo da modifiche al ramo principale, non c'è bisogno di pasticciare con il webook github. Puoi semplicemente usare il ramo git plugins per specificare che questo lavoro deve essere eseguito solo per il ramo master.

2. Impostare un lavoro per utilizzare il plug-in Github PUll Request Builder come consigliato, verrà attivato solo per un PR, per le 3 condizioni elencate.

3. quello più difficile .. Per quanto ne so, non esiste un modo facile per Jenkins sapere se un ramo ha una richiesta di pull o no, come le richieste di pull sono specifici per github, e la rilevazione Jenkins ramo è usando solo git.

Tuttavia, dalla mia esperienza, per questa terza opzione, ho installato un lavoro <project>-feature, e configurato per adattarsi a qualsiasi ramo con prefisso f/. In questo modo, se uno sviluppatore voleva che i test eseguissero automaticamente contro il loro ramo, ma non volesse aprire una richiesta di pull contro di esso, potrebbero creare un ramo come f/add_a_thing e automaticamente attiverà test sui push. Perché ciò funzioni, impostare lo specificatore del ramo su f/* nella configurazione del lavoro.

In alternativa, il plugin git consente un parametro di espressione regolare allo specificatore di ramo. È possibile utilizzare un'espressione regolare per ignorare in modo specifico il ramo principale. Tuttavia, l'unico modo per ignorare i rami richiesti di pull, consiste nel fare in modo che gli sviluppatori utilizzino uno schema di denominazione, ad esempio pr/add_a_thing, per identificare che questo ramo avrà una richiesta pull con esso.