@@ -14,9 +14,9 @@ the moment your code lands on `master`.
14
14
This guide will use that API to demonstrate a setup that you can use.
15
15
In our scenario, we will:
16
16
17
- * Merge aPull Request
18
- * When the CI is finished, we'll set thePull Request 's status accordingly.
19
- * When thePull Request is merged, we'll run our deployment to our server.
17
+ * Merge apull request
18
+ * When the CI is finished, we'll set thepull request 's status accordingly.
19
+ * When thepull request is merged, we'll run our deployment to our server.
20
20
21
21
Our CI system and host server will be figments of our imagination. They could be
22
22
Heroku, Amazon, or something else entirely. The crux of this guide will be setting up
@@ -50,7 +50,7 @@ Start this server up. By default, Sinatra starts on port `4567`, so you'll want
50
50
to configure ngrok to start listening for that, too.
51
51
52
52
In order for this server to work, we'll need to set a repository up with a webhook.
53
- The webhook should be configured to fire whenever aPull Request is created, or merged.
53
+ The webhook should be configured to fire whenever apull request is created, or merged.
54
54
Go ahead and create a repository you're comfortable playing around in. Might we
55
55
suggest[ @octocat 's Spoon/Knife repository] ( https://github.com/octocat/Spoon-Knife ) ?
56
56
After that, you'll create a new webhook in your repository, feeding it the URL
@@ -64,10 +64,10 @@ Great! Click on **Let me select individual events.**, and select the following:
64
64
65
65
* Deployment
66
66
* Deployment status
67
- * Pull Request
67
+ * pull request
68
68
69
69
These are the events {{ site.data.variables.product.product_name }} will send to our server whenever the relevant action
70
- occurs. We'll configure our server to* just* handle whenPull Requests are merged
70
+ occurs. We'll configure our server to* just* handle whenpull requests are merged
71
71
right now:
72
72
73
73
``` ruby