You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So now we've covered all of the major features and workflows of GitHub, but any large group or project will have customizations they may want to make or external services they may want to integrate.
5
+
6
+
Luckily for us, GitHub is really quite hackable in many ways. In this section we'll cover how to use the GitHub hooks system and it's API to make GitHub work how we want it to.
7
+
3
8
==== Hooks
4
9
10
+
The Hooks and Services section of GitHub repository administration is the easiest way to have GitHub interact with external systems.
11
+
12
+
===== Services
13
+
14
+
First we'll take a look at Services. Both the Hooks and Services integrations can be found in the Settings section of your repository, where we previously looked at adding Collaborators and changing the default branch of your project. Under the ``Webhooks and Services'' tab you will see something like <<_services_hooks>>.
15
+
16
+
[[_services_hooks]]
17
+
.Services and Hooks configuration section.
18
+
image::images/scripting-01-services.png[Services and hooks]
19
+
20
+
There are dozens of services you can choose from, most of them integrations into other commercial and open source systems. Most of them are for Continuous Integration services, bug and issue trackers, chat room systems and documentation systems. We'll walk through setting up a very simple one, the Email hook. If you choose ``email'' from the ``Add Service'' dropdown, you'll get a configuration screen like <<_service_config>>.
In this case, if we hit the ``Add service'' button, the email address we specified will get an email every time someone pushes to the repository. Services can listen for lots of different types of events, but most only listen for push events and then do something with that data.
27
+
28
+
If there is a system you are using that you would like to integrate with GitHub, you should check here to see if there is an existing service integration available. For example, if you're using Jenkins to run tests on your codebase, you can enable the Jenkins builtin service integration to kick off a test run every time someone pushes to your repository.
29
+
30
+
===== Hooks
31
+
32
+
If you need something more specific or you want to integrate with a service or site that is not included in this list, you can instead use the more generic hooks system. GitHub repository hooks are pretty simple. You specify a URL and GitHub will post an HTTP payload to that URL on any event you want.
33
+
34
+
Generally the way this works is you can setup a small web service to listen for a GitHub hook payload and then do something with the data when it is received.
35
+
36
+
To enable a hook, you click the ``Add webhook'' button in <<_services_hooks>>. This will bring you to a page that looks like <<_web_hook>>.
37
+
38
+
[[_web_hook]]
39
+
.Web hook configuration.
40
+
image::images/scripting-03-webhook.png[Web hook]
41
+
42
+
The configuration for a web hook is pretty simple. In most cases you simply enter a URL and a secret key and hit ``Add webhook''. There are a few options for which events you want GitHub to send you a payload for -- the default is to only get a payload for the `push` event, when someone pushes new code to any branch of your repository.
43
+
44
+
Let's see a small example of a web service you may set up to handle a web hook. We'll use the Ruby web framework Sinatra since it's fairly concise and you should be able to easily see what we're doing.
45
+
46
+
Let's say we want to get an email if a specific person pushes to a specific branch of our project modifying a specific file. We could fairly easily do that with code like this:
47
+
48
+
[source,ruby]
49
+
----
50
+
require 'sinatra'
51
+
require 'json'
52
+
require 'mail'
53
+
54
+
post '/payload' do
55
+
push = JSON.parse(request.body.read) # parse the JSON
Here we're taking the JSON payload that GitHub delivers us and looking up who pushed it, what branch they pushed to and what files were touched in all the commits that were pushed. Then we check that against our criteria and send an email if it matches.
83
+
84
+
In order to develop and test something like this, you have a nice developer console in the same screen where you set the hook up. You can see the last few deliveries that GitHub has tried to make for that webhook. For each hook you can dig down into when it was delivered, if it was successful and the body and headers for both the request and the response. This makes it incredibly easy to test and debug your hooks.
The other great feature of this is that you can redeliver any of the payloads to test your service easily.
91
+
92
+
For more information on how to write webhooks and all the different event types you can listen for, go to the GitHub Developer documentation at: https://developer.github.com/webhooks/
93
+
5
94
==== The GitHub API
6
95
7
96
(((GitHub, API)))
8
-
If the web UI isn't enough for you, or you're writing a program that works with GitHub projects, you'll be happy to know that GitHub has an API.
9
-
It works over HTTPS, so it's fairly easy to try out:
97
+
Services and hooks give you a way to receive push notifications about events that happen on your repositories, but what if you need more information about these events? What if you need to automate something like adding collaborators or labeling issues?
98
+
99
+
This is where the GitHub API comes in handy. GitHub has tons of API endpoints for doing nearly anything you can do on the website in an automated fashion. In this section we'll learn how to authenticate and connect to the API, how to comment on an issue and how to change the status of a Pull Request through the API.
100
+
101
+
==== Basic Usage
102
+
103
+
The most basic thing you can do is a simple GET request on an endpoint that doesn't require authentication. This could be a user or read-only information on an open source project. For example, if we want to know more about a user named ``schacon'', we can run something like this:
Most everything you can do from the GitHub web interface or from Git itself can be done through this API, as well as some things that can't.
26
-
Remember how `gh` can convert an issue into a pull request?
27
-
That's accomplished using the a `POST` to the `/repos/<owner>/<repo>/pulls` endpoint.
119
+
==== Commenting on an Issue
28
120
29
-
Several open-source libraries exist that make this API available in an idiomatic way.
30
-
At the time of this writing, the supported languages include Go, Objective-C, Ruby, and .NET.
31
-
Check out http://github.com/octokit[] for more information on these, as they handle much of the HTTP for you.
121
+
- Issues API
122
+
123
+
==== Changing the Status of a Pull Request
32
124
33
-
There's much more to the API than is possible to cover in this book.
34
-
Take a look at https://developer.github.com[] for the complete documentation, as well as guides for common tasks.
125
+
- PR status API
35
126
36
-
- PR status API
37
-
- Issues API
38
-
- Search API
39
-
- deployment API (https://developer.github.com/changes/2014-01-09-preview-the-new-deployments-api/)
40
127
41
-
==== Applications and OAuth
42
128
43
-
- access tokens
44
-
- authorized applications
45
-
- developer applications
129
+
Though we've been doing everything through `curl` in these examples, several open-source libraries exist that make this API available in a more idiomatic way.
130
+
At the time of this writing, the supported languages include Go, Objective-C, Ruby, and .NET.
131
+
Check out http://github.com/octokit[] for more information on these, as they handle much of the HTTP for you.
46
132
47
-
- two factor authentiation
133
+
For complete documentation on the entire API as well as guides for common tasks, check out https://developer.github.com[].
0 commit comments