Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings
This repository was archived by the owner on Nov 1, 2017. It is now read-only.

Commitf5c5a2f

Browse files
committed
Some slight cleanup
1 parentfe8b0c2 commitf5c5a2f

File tree

2 files changed

+16
-18
lines changed

2 files changed

+16
-18
lines changed

‎content/guides/building-a-ci-server.md‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -55,7 +55,7 @@ suggest [@octocat's Spoon/Knife repository](https://github.com/octocat/Spoon-Kni
5555
After that, you'll create a new webhook in your repository, feeding it the URL
5656
that ngrok gave you:
5757

58-
![A new ngrok URL](/images/webhooks_recent_deliveries.png)
58+
![A new ngrok URL](/images/webhook_sample_url.png)
5959

6060
Click**Update webhook**. You should see a body response of`Well, it worked!`.
6161
Great! Click on**Let me select individual events.**, and select the following:

‎content/guides/delivering-deployments.md‎

Lines changed: 15 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -7,9 +7,9 @@ title: Delivering deployments | GitHub API
77
* TOC
88
{:toc}
99

10-
The[Deployment API][deploy API] provides your projects hosted on GitHub with
10+
The[Deployments API][deploy API] provides your projects hosted on GitHub with
1111
the capability to launch them on a production server that you own. Combined with
12-
[thestatus API][status API], you'll be able to coordinate your deployments
12+
[theStatus API][status API], you'll be able to coordinate your deployments
1313
the moment your code lands on`master`.
1414

1515
This guide will use that API to demonstrate a setup that you can use.
@@ -57,7 +57,7 @@ suggest [@octocat's Spoon/Knife repository](https://github.com/octocat/Spoon-Kni
5757
After that, you'll create a new webhook in your repository, feeding it the URL
5858
that ngrok gave you:
5959

60-
![A new ngrok URL](/images/webhooks_recent_deliveries.png)
60+
![A new ngrok URL](/images/webhook_sample_url.png)
6161

6262
Click**Update webhook**. You should see a body response of`Well, it worked!`.
6363
Great! Click on**Let me select individual events.**, and select the following:
@@ -67,7 +67,8 @@ Great! Click on **Let me select individual events.**, and select the following:
6767
* Pull Request
6868

6969
These are the events GitHub will send to our server whenever the relevant action
70-
occurs. We'll configure our server to*just* handle the Pull Request scenario right now:
70+
occurs. We'll configure our server to*just* handle when Pull Requests are merged
71+
right now:
7172

7273
#!ruby
7374
post '/event_handler' do
@@ -76,7 +77,7 @@ occurs. We'll configure our server to *just* handle the Pull Request scenario ri
7677
case request.env['HTTP_X_GITHUB_EVENT']
7778
when "pull_request"
7879
if @payload["action"] == "closed" && @payload["pull_request"]["merged"]
79-
puts "A pull request was merged! Adpeloyment should start now..."
80+
puts "A pull request was merged! Adeployment should start now..."
8081
end
8182
end
8283
end
@@ -103,9 +104,12 @@ merged, and start paying attention to deployments:
103104
end
104105
when "deployment"
105106
process_deployment(@payload)
107+
when "deployment_status"
108+
update_deployment_status
106109
end
107110

108-
Based on the information from the pull request, we'll fill out the`start_deployment` method:
111+
Based on the information from the pull request, we'll start by filling out the
112+
`start_deployment` method:
109113

110114
#!ruby
111115
def start_deployment(pull_request)
@@ -126,7 +130,7 @@ Deployments can take a rather long time, so we'll want to listen for various eve
126130
such as when the deployment was created, and what state it's in.
127131

128132
Let's simulate a deployment that does some work, and notice the effect it has on
129-
the output. First, let'swrite our`process_deployment` method:
133+
the output. First, let'scomplete our`process_deployment` method:
130134

131135
#!ruby
132136
def process_deployment
@@ -139,13 +143,6 @@ the output. First, let's write our `process_deployment` method:
139143
@client.create_deployment_status("repos/#{@payload['repository']['full_name']}/deployments/#{@payload['id']}", 'success')
140144
end
141145

142-
We'll also add a new case to the`switch` statement for deployment statuses:
143-
144-
#!ruby
145-
when "deployment_status"
146-
update_deployment_status
147-
end
148-
149146
Finally, we'll simulate storing the status information as console output:
150147

151148
#!ruby
@@ -155,11 +152,12 @@ Finally, we'll simulate storing the status information as console output:
155152

156153
Let's break down what's going on. A new deployment is created by`start_deployment`,
157154
which triggers the`deployment` event. From there, we call`process_deployment`
158-
to simulate work that's going on. Meanwhile, we also make a call to`create_deployment_status`,
159-
which lets a receiver know what's going on, as we switch the status to`pending`.
155+
to simulate work that's going on. During that processing, we also make a call to
156+
`create_deployment_status`, which lets a receiver know what's going on, as we
157+
switch the status to`pending`.
160158

161159
After the deployment is finished, we set the status to`success`. You'll notice
162-
that this pattern is the exact same as when weupdated our CIstatus.
160+
that this pattern is the exact same as when weyou your CIstatuses.
163161

164162
##Conclusion
165163

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp