Comment traiter un github webhook charge dans Jenkins?

Il y a quelques astuces pour obtenir ce travail, et j'ai trouvé la (défunte) chloky.com billet de blog pour être utile pour la plupart. Car il sonne comme vous avez pu le webhook communiquer avec votre instance Jenkins au moins, je vais sauter par-dessus les étapes pour l'instant. Mais, si vous voulez plus de détails, il suffit de faire défiler passé la fin de ma réponse pour voir le contenu, j'ai été en mesure de récupérer à partir de chloky.com - je ne connais pas l'auteur original, et les informations peuvent être obsolètes, mais je n'ai trouver qu'il est utile.

Donc, pour résumer, vous pouvez effectuer les opérations suivantes à traiter avec la charge utile:

1. Configurer un paramètre de chaîne appelée "charge utile" dans votre Jenkins travail. Si vous envisagez sur l'exécution manuelle de la construction, il pourrait être une bonne idée pour lui donner une valeur par défaut document JSON à un certain point, mais vous n'en avez pas besoin maintenant. Ce nom de paramètre semble être sensible à la casse (je suis sous Linux donc c'est pas une surprise...)

2. Configurer le webhook dans github, pour utiliser le buildWithParameters point de terminaison de la place de la construire d'extrémité, c'est à dire
   http://<<yourserver>>/job/<<yourjob>>/buildWithParameters?token=<<yourtoken>>

3. Configurer votre webhook à utiliser application/x-www-form-codé au lieu de application/json. La première approche des packs de données JSON dans une variable de formulaire appelé "charge utile", qui est sans doute la façon Jenkins pouvez l'affecter à une variable d'environnement. Le application/json approche juste Postes de raw JSON qui ne semble pas être transposable à n'importe quoi (je ne pouvais pas le faire fonctionner). Vous pouvez voir la différence en pointant votre webhook à quelque chose comme requestbin et inspecter les résultats.

4. À ce stade, vous devriez obtenir votre $de la charge utile variable lorsque vous le coup d'envoi de la construction. Pour parser le JSON, je recommande fortement l'installation de jq sur votre serveur Jenkins et essayer certains de l'analyse de la syntaxe ici. JQ est particulièrement agréable car il est multi-plateforme.
5. À partir d'ici, il suffit d'analyser ce que vous avez besoin de le JSON dans d'autres variables d'environnement. Combiné avec conditionnelle étapes de génération, ce qui pourrait vous donner un peu de souplesse.

Espérons que cette aide!

---

MODIFIER voici ce que j'ai pu saisir de l'origine des messages de blog à http://chloky.com/tag/jenkins/, qui a été mort pendant un certain temps.
J'espère que ce contenu est également utile pour quelqu'un.

---

Post #1 - Juillet 2012

Github fournit un bon moyen de déclencher des notifications à un système CI comme jenkins chaque fois qu'une livraison est faite à l'encontre d'un référentiel. Ceci est vraiment utile pour le coup d'envoi de favoriser l'emploi dans jenkins pour tester les commits qui ont été faites sur le repo. Vous avez simplement besoin d'aller à la section de l'administration du référentiel, cliquez sur service de crochets sur la gauche, cliquez sur " webhook Url en haut de la liste, puis entrez l'URL de la webhook que jenkins attend (regardez ce plugin jenkins pour configurer jenkins pour recevoir ces crochets à partir de github).

Mais récemment, je cherchais un moyen de faire un webhook feu lorsqu'une demande d'extraction est faite à l'encontre d'un repo, plutôt que lorsqu'un commit est fait pour les pensions de titres. C'est ainsi que l'on pourrait avoir jenkins exécuter un tas de tests sur les pull request, avant de décider de fusionner les demande de pull in – utile lorsque vous avez beaucoup de développeurs qui travaillent sur leur propre fourches et en soumettant régulièrement tirer les demandes vers les principales repo.

Il s'avère que ce n'est pas aussi évident qu'on pourrait l'espérer, et nécessite un peu de vous embêter avec l'API github.

Par défaut, lorsque vous configurez un github webhook, il est configuré pour que du feu, lorsqu'un commit est fait à l'encontre d'un repo. Il n'est pas facile à voir, ou à changer, et ce dans le github de l'interface web lorsque vous configurez le webhook. Dans le but de manipuler la webhook en aucune façon, vous devez utiliser l'API.

De faire des changements sur les pensions de titres via l'API github, nous avons besoin de nous autoriser à nous-mêmes. Nous allons utiliser curl, de sorte que si nous le voulions, nous pourrions passer notre nom d'utilisateur et le mot de passe à chaque fois, comme ceci:

# curl https://api.github.com/users/mancdaz --user 'mancdaz'
Enter host password for user 'mancdaz':

Ou, et c'est une bien meilleure option si vous souhaitez script tout ça, on peut prendre un jeton oauth et de l'utiliser dans les requêtes suivantes pour éviter de devoir garder l'entrée de notre mot de passe. C'est ce que nous allons faire dans notre exemple. Nous devons d'abord créer une autorisation oauth et prenez le jeton:

curl https://api.github.com/authorizations --user "mancdaz" \
--data '{"scopes":["repo"]}' -X POST

Vous sera retourné à quelque chose comme:

{
   "app":{
      "name":"GitHub API",
      "url":"http://developer.github.com/v3/oauth/#oauth-authorizations-api"
   },
   "token":"b2067d190ab94698a592878075d59bb13e4f5e96",
   "scopes":[
      "repo"
   ],
   "created_at":"2012-07-12T12:55:26Z",
   "updated_at":"2012-07-12T12:55:26Z",
   "note_url":null,
   "note":null,
   "id":498182,
   "url":"https://api.github.com/authorizations/498182"
}

Maintenant, nous pouvons utiliser ce jeton dans les requêtes suivantes pour la manipulation de notre compte github via l'API. Donc, nous allons interroger notre repo et de trouver la webhook nous avons mis en place dans l'interface web plus tôt:

# curl  https://api.github.com/repos/mancdaz/mygithubrepo/hooks?access_token=b2067d190ab94698592878075d59bb13e4f5e96
[
  {
    "created_at": "2012-07-12T11:18:16Z",
    "updated_at": "2012-07-12T11:18:16Z",
    "events": [
      "push"
    ],
    "last_response": {
      "status": "unused",
      "message": null,
      "code": null
    },
    "name": "web",
    "config": {
      "insecure_ssl": "1",
      "content_type": "form",
      "url": "http://jenkins-server.chloky.com/post-hook"
    },
    "id": 341673,
    "active": true,
    "url": "https://api.github.com/repos/mancdaz/mygithubrepo/hooks/341673"
  }
]

Remarque les bits importants de cette sortie json:

"events": [
      "push"
    ]

Cela dit en gros que ce webhook ne sera déclenchée que lorsqu'un commit (push) est faite pour les pensions de titres. La documentation de l'API github décrit de nombreux différents types d'événements qui peuvent être ajoutés à cette liste – pour nos fins, nous voulons ajouter pull_request, et c'est comment nous le faisons (notez que nous obtenir l'id de la webhook de la sortie json ci-dessus. Si vous avez plusieurs crochets défini, votre sortie contiendra tous ces crochets pour être sûr d'obtenir le bon ID):

# curl  https://api.github.com/repos/mancdaz/mygithubrepo/hooks/341673?access_token=b2067d190ab94698592878075d59bb13e4f5e96 -X PATCH --data '{"events": ["push", "pull_request"]}'
{
  "created_at": "2012-07-12T11:18:16Z",
  "updated_at": "2012-07-12T16:03:21Z",
  "last_response": {
    "status": "unused",
    "message": null,
    "code": null
  },
  "events": [
    "push",
    "pull_request"
  ],
  "name": "web",
  "config": {
    "insecure_ssl": "1",
    "content_type": "form",
    "url": "http://jenkins-server.chloky.com/post-hook"
  },
  "id": 341673,
  "active": true,
  "url": "https://api.github.com/repos/mancdaz/mygithubrepo/hooks/341673"
}

Voir!

"events": [
    "push",
    "pull_request"
  ],

Ce webhook déclenche désormais à chaque fois qu'un commit OU un pull request est faite à l'encontre de notre repo. Exactement ce que vous faites dans votre jenkins/avec ce webhook est à vous. Nous l'utilisons pour le coup d'envoi d'un tas de tests d'intégration dans jenkins pour tester le projet de patch, et puis les fusionner et à proximité (à nouveau à l'aide de l'API) de la demande d'extraction automatique. Assez doux.

Post #2 - Septembre 2012

Dans un précédent post, j'ai parlé à propos de la configuration de l'github webhook à feu sur une pull request, plutôt que de simplement un commit. Comme mentionné, il ya beaucoup d'événements qui se produisent sur un dépôt github, et comme par le github de la documentation, un grand nombre de ces peut être utilisé pour déclencher le webhook.

Peu importe quel événement vous décidez de déclencher, lorsque le webhook feux de github, il est essentiellement fait un POST à l'URL configurée dans le webhook, y compris une charge utile json dans le corps. La charge utile json contient diverses informations sur l'événement qui a provoqué le webhook à feu. Un exemple de charge utile que le feu sur un simple commit peut être vu ici:

payload
{
"after":"c04a2b2af96a5331bbee0f11fe12965902f5f571",
"before":"78d414a69db29cdd790659924eb9b27baac67f60",
"commits":[
{
"added":[
"afile"
],
"author":{
"email":"[email protected]",
"name":"Darren Birkett",
"username":"mancdaz"
},
"committer":{
"email":"[email protected]",
"name":"Darren Birkett",
"username":"mancdaz"
},
"distinct":true,
"id":"c04a2b2af96a5331bbee0f11fe12965902f5f571",
"message":"adding afile",
"modified":[
],
"removed":[
],
"timestamp":"2012-09-03T02:35:59-07:00",
"url":"https://github.com/mancdaz/mygithubrepo/commit/c04a2b2af96a5331bbee0f11fe12965902f5f571"
}
],
"compare":"https://github.com/mancdaz/mygithubrepo/compare/78d414a69db2...c04a2b2af96a",
"created":false,
"deleted":false,
"forced":false,
"head_commit":{
"added":[
"afile"
],
"author":{
"email":"[email protected]",
"name":"Darren Birkett",
"username":"mancdaz"
},
"committer":{
"email":"[email protected]",
"name":"Darren Birkett",
"username":"mancdaz"
},
"distinct":true,
"id":"c04a2b2af96a5331bbee0f11fe12965902f5f571",
"message":"adding afile",
"modified":[
],
"removed":[
],
"timestamp":"2012-09-03T02:35:59-07:00",
"url":"https://github.com/mancdaz/mygithubrepo/commit/c04a2b2af96a5331bbee0f11fe12965902f5f571"
},
"pusher":{
"email":"[email protected]",
"name":"mancdaz"
},
"ref":"refs/heads/master",
"repository":{
"created_at":"2012-07-12T04:17:51-07:00",
"description":"",
"fork":false,
"forks":1,
"has_downloads":true,
"has_issues":true,
"has_wiki":true,
"name":"mygithubrepo",
"open_issues":0,
"owner":{
"email":"[email protected]",
"name":"mancdaz"
},
"private":false,
"pushed_at":"2012-09-03T02:36:06-07:00",
"size":124,
"stargazers":1,
"url":"https://github.com/mancdaz/mygithubrepo",
"watchers":1
}
}

Toute cette charge utile est transmis dans les requêtes POST comme paramètre unique, avec de l'imagination de titre payload. Il contient une tonne d'information sur l'événement qui vient de se produire, qui peut être utilisé par jenkins, lorsque nous construisons des emplois après le déclenchement. Afin d'utiliser cette charge dans Jenkins, nous avons un couple d'options. Je discute ci-dessous.

Obtenir l' $de la charge utile

Dans jenkins, lors de la création d'un nouveau travail, nous avons la possibilité de spécifier les noms des paramètres que nous nous attendons à passer à l'emploi dans le POST qui déclenche la construction. Dans ce cas, on introduit un paramètre unique payload, comme on le voit ici:

Passer des paramètres à un jenkins travail

Plus bas dans la configuration d'une tâche, on peut préciser que nous aimerions être en mesure de déclencher le construire à distance (ie. que nous voulons permettre à github pour déclencher la construire en publiant sur notre URL de la charge utile):

Puis, quand nous avons créé l'webhook dans notre dépôt github (comme décrit dans le premier post), nous donner l'URL que jenkins nous dit:

Vous ne pouvez pas les voir tous dans la screencap, mais l'URL que j'ai spécifié pour le webhook était celui que jenkins a dit de moi:

http://jenkins-server.chloky.com:8080/job/mytestbuild//buildWithParameters?token=asecuretoken
Maintenant, quand j'ai construit mon nouveau travail de jenkins, pour les besoins de ce test, j'ai simplement dit à l'écho le contenu de la charge utile de paramètre (qui est disponible dans paramterized construit comme une variable d'environnement du même nom), à l'aide d'un simple script:

#!/bin/bash
echo "the build worked! The payload is $payload"

Maintenant pour tester le tout, nous avons simplement à faire un commit sur notre repo, et puis plus pop à jenkins de regarder le travail qui a été déclenchée:

mancdaz@chloky$ (git::master)$ touch myfile
mancdaz@chloky$ (git::master) git add myfile
mancdaz@chloky$ (git::master) git commit -m 'added my file'
[master 4810490] added my file
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 myfile
mancdaz@chloky$ (git::master) git push
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 232 bytes, done.
Total 2 (delta 1), reused 0 (delta 0)
To git@github.com:mancdaz/mygithubrepo.git
c7ecafa..4810490 master -> master

Et plus dans notre jenkins serveur, nous pouvons regarder à la sortie de la console de l'emploi qui a été déclenchée, et voilà il est notre "charge utile" contenues dans le $charge variable et disponible pour nous de consommer:

Si grande, toutes les infos sur notre github de l'événement est ici. et totalement disponibles dans notre jenkins travail! Certes, il est dans un grand json blob, mais avec un peu d'astucieux bash vous devriez être bon d'aller.

Bien sûr, cet exemple simple de s'engager à démontrer les principes de connaître la charge utile à l'intérieur de jenkins. Comme nous l'avons évoqué dans le précédent post, un commit est l'un des nombreux événements sur les pensions de titres qui peuvent déclencher un webhook. Ce que vous faites à l'intérieur de jenkins, une fois que vous avez déclenché est à vous, mais le vrai plaisir vient quand vous commencez à interagir avec github, pour prendre de nouvelles mesures sur le repo (poster des commentaires, de fusion pull requests, rejeter les livraisons, etc) sur la base des résultats de votre construction emplois qui l'a déclenchée par l'événement initial.

Regarder dehors pour un prochain post où je lier tout cela ensemble et vous montrer comment le processus, exécution de tests, et enfin fusion pull request en cas de succès, tout à fait automatiquement à l'intérieur de jenkins. L'automatisation, c'est amusant!

OriginalL'auteur killthrush