输入以下命令检查操作是否成功：
$ sudo systemctl status buildbot-master ● buildbot-master.service - BuildBot master service Loaded: loaded (/etc/systemd/system/buildbot-master.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2017-06-27 19:24:07 UTC; 2s ago Main PID: 8298 (buildbot) Tasks: 2 Memory: 51.7M CPU: 1.782s CGroup: /system.slice/buildbot-master.service └─8298 /usr/bin/python /usr/local/bin/buildbot start --nodaemon Jun 27 19:24:07 bb5 systemd[1]: Started BuildBot master service如果服务能够成功重新启动，则会将其标记为活动状态。
在示例存储库中创建GitHub Webhook
现在Buildbot配置了一个Web端点来接受GitHub webhook帖子，我们可以为我们的fork配置一个webhook。
在Web浏览器中，导航到示例项目存储库的fork：
https://github.com/your_github_user/hello_hapi单击“设置”选项卡以查看项目设置。在设置页面的左侧菜单中，单击Webhooks（GitHub可能会提示您在此过程中重新输入密码以确认您的身份）：
单击右侧的“ 添加webhook”按钮以添加新的webhook。
下面的页面将包含一个用于定义webhook的表单。在Payload URL字段中，添加项目的GitHub更改的URL。这是通过指定https://协议，然后是Buildbot master的域名，然后是/change_hook/github构建的。
将内容类型设置为application/x-www-form-urlencoded。在“密码”字段中，输入您在Buildbot主配置文件中选择的秘密密码。您可以选中“Just push”事件触发器，勾选“Active”复选框：
完成后，单击“ 添加webhook”按钮。
您将返回到项目的webhooks索引，在该索引中将显示您的新webhook。如果刷新几次，则应在webhook旁边显示绿色复选标记图标，表示邮件已成功传输：
如果您看到红色的X，请再次单击webhook，然后向下滚动到Recent Deliveries部分。如果您单击failed delivery，可以获得有关出现问题的更多信息。
测试Webhook现在我们已经有了webhook，我们可以测试以确保当我们对存储库进行更改时，Buildbot会被警告，触发Docker中的构建，并且能够成功执行测试套件。
在GitHub fork的主页面中，单击绿色“克隆或下载”按钮左侧的“ 创建新文件 ”按钮：
在随后的屏幕上，创建dummy_file并填写一些文本：
完成后，单击页面底部的“ 提交新文件”按钮。
接下来，访问您的Buildbot Web界面，如果您尚未通过身份验证，请登录。
根据您提交dummy_file到存储库后的时间长度，您可能会看到正在进行的构建，如下所示：
如果构建已经完成，则它将位于“最近构建”部分中：
我们定义的构建器名称“npm”用于标记构建。在该示例中，我们还可以从先前的主配置中看到较早的样本构建器运行。
无论进度如何，单击构建器名称和内部版本号链接以访问构建详细信息页面。此视图包含有关所执行的构建的信息。我们添加到构建工厂的每个步骤都将显示在其自己的部分中：
如果单击某个步骤，将显示该命令的输出。如果出现问题，这可以帮助调试：
在上面的输出中，我们可以验证Buildbot是否在我们的测试套件中成功运行了三个测试。
如果构建未成功完成，您可能希望检查的其他一些区域是构建详细信息页面上的其他选项卡以及/home/buildbot/master/twistd.log文件。
调整Buildbot服务
在我们完成之前，我们应该对我们的Buildbot服务进行一些调整。
目前，我们为不再使用的工作人员定义了buildbot-worker服务（我们的Docker工作程序在需要时自动启动）。
我们应该停止并禁用old worker。