我们使用相同的方法将配置附加到空列表中。在这种情况下，我们附加一个schedulers.SingleBranchScheduler实例。这允许我们在存储库中观察单个分支，并简化了配置。
我们将调度程序命名为“hello_hapi”以正确识别它。然后我们定义一个更改过滤器。来自不同来源的许多不同变更集可以交给调度程序。更改过滤器定义一组标准，用于确定此特定调度程序是否应处理相关更改。在我们的例子中，我们根据项目名称进行过滤，这将由GitHub webhook和我们希望观看的分支报告。
接下来，我们将treeStableTimer设置为3秒，该treeStableTimer确定等待其他更改的时间量。这有助于防止Buildbot为与密切相关的更改排队许多小型构建。最后，我们定义当更改符合我们的条件时应该使用的构建器的名称（我们将暂时定义此为构建器）。
为Node.js项目配置构建工厂
接下来，我们将配置一个用于处理Node.js项目的构建工厂。构建工厂负责定义构建或在我们的案例测试中应该采取的步骤。它通过定义util.BuildFactory实例然后添加应执行的顺序步骤来完成此操作。
将以下内容粘贴到文件的底部：
/home/buildbot/master/master.cfg
. . . # Build Factories npm_f = util.BuildFactory() npm_f.addStep(steps.GitHub(repourl='git://github.com/your_github_name/hello_hapi.git', mode='full', method='clobber')) npm_f.addStep(steps.ShellCommand(command=["npm", "install"])) npm_f.addStep(steps.ShellCommand(command=["npm", "test"]))首先，我们定义一个名为npm_f的构建工厂。我们添加的第一步是steps.GitHub实例。在这里，我们设置应该下拉到构建器中的存储库。我们设置mode为“full”和method“clobber”以在每次提取新代码时完全清理我们的存储库。
我们添加的第二个和第三个步骤是steps.ShellCommand对象，它们定义在构建期间在存储库中运行的shell命令。在我们的例子中，我们需要运行npm install以收集项目的依赖项。之后，我们需要运行npm test以运行我们的测试套件。在大多数情况下，建议将命令定义为一个list (["npm","install"]），以防止shell对命令中的元素应用不需要的扩展。
配置构建器
一旦我们有一个添加了步骤的构建工厂，我们就可以设置一个构建器。构建器将我们已定义的许多元素绑定在一起，以确定构建的执行方式。
将以下配置粘贴到文件的底部：
/home/buildbot/master/master.cfg
. . . # Builders c['builders'] = [] c['builders'].append( util.BuilderConfig(name="npm", workernames=["npm-docker-worker"], factory=npm_f))我们将一个util.BuilderConfig对象附加到builders列表中。请记住，我们的构建工厂名为npm_f，我们的Docker工作者称为npm-docker-worker，我们定义的调度程序将把任务传递给名为npm的worker。。我们的构建器定义了这些元素之间的关系，以便我们的调度程序的更改将导致构建工厂步骤在Docker worker中执行。
配置数据库和Web界面
最后，我们可以配置数据库和Web界面设置。与之前的许多项目不同，这两个设置被定义为字典而不是列表。该db字典只指向/home/buildbot/master目录中已有的state.sqlite文件。www词典包含大量额外配置。
将以下内容粘贴到文件的底部。将您从原始Buildbot主配置中复制的身份验证信息替换为以下身份验证块：
/home/buildbot/master/master.cfg
. . . # Database c['db'] = { 'db_url': "sqlite:///state.sqlite",} # Web Interface c['www'] = dict(port=8010, plugins=dict(waterfall_view={}, console_view={})) # Auth info copied from the original configuration c['www']['authz'] = util.Authz( allowRules = [ util.AnyEndpointMatcher(role="admins") ], roleMatchers = [ util.RolesFromUsername(roles=['admins'], usernames=['Sammy']) ] ) c['www']['auth'] = util.UserPasswordAuth({'Sammy': 'Password'}) # End of auth info copied from the original configuration # GitHub webhook receiver c['www']['change_hook_dialects'] = { 'github': { 'secret': 'your_secret_value', 'strict': True, } }在定义数据库设置之后，我们创建一个www字典，该字典首先定义要侦听的端口以及要包含在Web UI中的一些视图。接下来，我们添加从先前的Buildbot配置文件中提取的身份验证要求。
最后，我们在www字典中定义了一个名为change_hook_dialects的字典。我们使用它来定义一个GitHub更改挂钩，它将侦听来自GitHub的webhook消息。为您的机密选择一个安全密码，GitHub将使用该密码来验证它将发送的消息。
完成后，保存并关闭文件。
重新启动Buildbot Master以应用新配置此时，我们已经完全重新配置了Buildbot主进程。我们需要重新启动Buildbot主进程来实现更改。
在我们这样做之前，检查我们的文件是否有重要的语法错误。由于我们从头开始重建配置，因此我们很可能会引入一些错误。
输入以下命令检查文件的语法：
$ sudo buildbot checkconfig /home/buildbot/master该命令将报告它找到的任何问题。如果未找到任何错误，您将收到如下消息：
Config file is good!如果报告了任何错误，请仔细阅读错误消息，以便更好地了解错误。再次打开配置文件以尝试解决任何问题。
如果不再出现任何错误，请输入以下命令重新启动Buildbot主服务：
$ sudo systemctl restart buildbot-master