autobot 0.1.1

什么是autobot？

autobot是一个构建在buildbot前端上的持续集成解决方案。我们有很多软件。我们很优秀，所以通常不会出错。但我们不是万能的。我们的机器人盟友autobot在这里为我们测试东西。让我们认识一下autobot！

安装autobot

可以使用安装脚本安装autobot

curl http://k0s.org/hg/autobot/raw-file/tip/INSTALL.sh | bash

这将创建一个虚拟环境并安装autobot以进行开发（$VIRTUAL_ENV/src/autobot）。您还可以使用脚本作为说明，以与其他任何Python包相同的方式安装它。

设置buildmaster和buildslave

一旦安装了autobot并激活了虚拟环境，您将想要创建一个buildmaster和一个buildslave。

在激活虚拟环境后，您可以通过运行create-autobot来创建一个主从对。这对于autobot开发非常有用。还有create-autobot-master和create-autobot-slave这两个脚本，它们在生产中更有用，因为通常您不会希望将主服务器和从服务器放在同一台机器上，除非是用于开发和测试。脚本将提示您输入工厂或您可以使用--factory或-f从命令行指定一个或多个。工厂来自autobot.projects及其子目录。您可以使用create-autobot --list-factories（或create-autobot-master --list-factories）列出可用的工厂。

运行 create-autobot --help 将显示创建新机器人时可设置的变量（create-autobot-master 和 create-autobot-slave 也支持 --help，其中 create-autobot 中的变量是这些的子集）。

如果您未指定变量，将使用默认值创建您的特定机器人。您可以在生成的配置中稍后更改这些变量。

使用 autobot

通过在机器人的目录中使用 buildbot start master 和 buildslave stop slave 启动 buildmaster 和 buildslave。相应的 stop 命令也存在。如果您使用了 create-autobot 命令，生成的机器人将有一个 restart_buildbot.py 脚本，该脚本将停止并启动主从（如果设置了调试）并删除日志。

生成的 master.cfg 文件从同一目录下的 master.ini 文件中读取值。master.ini 包含多个不同的部分

• [:master:] 包含主机的顶级配置以及从机的默认设置

• 如 [slave:slavename] 这样的部分表示名为 slavename 的从机

• 所有其他部分都是工厂的构建参数

关于 .ini 文件的格式在随后的部分中详细介绍。您可以通过编辑 master.cfg 文件来更改使用的 .ini 文件，或者，如果您出于任何原因不想使用 .ini 文件作为驱动程序，您可以在其中自行构建适当的配置。

在默认情况下，构建状态概述可以在瀑布显示中查看，默认位置为 http://localhost:8010/waterfall。要强制构建，请单击所需的构建器，底部将出现强制构建按钮。

重要的是要记住，持续集成是一个安全网，而不是第一道防线。换句话说，在将代码发送给 autobot 之前，继续检查您的代码。

.ini 文件格式

如上所述，master.ini 文件包含三种不同类型的部分

• [:master:] 包含主机的顶级配置以及从机的默认设置

• 如 [slave:slavename] 这样的部分表示名为 slavename 的从机

• 其他部分是工厂的构建参数

每个部分包含什么内容？

:master: 主机部分包含适用于 buildmaster 的参数

• slaveport: 监听从机的端口号

• htmlport: 服务器瀑布显示的端口号

• pollInterval: 多久轮询一次代码库，以秒为单位 [默认：60]

• treeStable: 在构建之前等待树稳定的时间 [默认：60]

其他默认值可以通过运行 create-autobot-master --help 查看。

[:master:] 部分中提供的其他参数用作每个从机的基线默认值。它们可以在每个 slave: 部分中覆盖

slave: 每个从机的参数

• password: 每个 slave 必须 有一个密码。除非有理由为每个从机设置不同的密码，否则最好将其放在 :master: 部分中

• 工厂：在从属节点上运行的工厂的空格分隔列表。如果使用特殊值 *，则将运行所有工厂。您可以使用 create-autobot --list-factories 查看可用的工厂。工厂名称对应于 autobot.projects 中的目录（或模块）名称。如果每个从属节点都应运行相同的工厂，则可以将此内容放入 :master: 部分。

• os：从属节点的操作系统。应该是 linux、win 或 mac 之一（尽管关于 MozInfo 的未来使用可能会使其过时）。您可能 不应该 在 :master: 部分为此设置默认键（尽管 autobot 不会阻止您这样做！）。

工厂部分：所有其他部分都用于构建工厂。在 master.cfg 中创建时，工厂部分中的每个参数都用作构造函数（__init__）关键字参数。因此，以下工厂部分

[foo]
bar = fleem
baz = another parameter

将在每个从属节点上调用 foo 工厂（假设它映射到 MyFooFactory）

MyFooFactory(**dict(bar='fleem', baz='another parameter'))

此外，如果工厂有一个特殊键 platform，从属节点将在实例化工厂时传递其平台信息。目前，这是一个包含单个键 os 的字典，但可能需要添加更多。如以下 TODO 中所述，理想情况下，这将完全由 MozInfo 弃用，但这是临时的解决方案。

来源

autobot.process.factory:SourceFactory 是一个抽象基类，用于指定来源。来源作为实例上的成员存在，命名为（奇怪地）sources。这是一个字典，其键是来源类型，值是要使用的来源。来源类型目前是“git”和“hg”，但这很容易扩展。

内部，单个来源存储为一个包含两个元素的元组，第一个元素是来源的 URL，第二个元素是分支。如果分支是 None 或未指定，则假定对于 git 等同于 master，对于 hg 等同于 default。但是，您也可以使用 URL#branch 的形式。此外，您可以指定一个空格分隔的来源，SourceFactory 将将其拆分为一个来源列表。

生成的 master.cfg 在给定的来源上轮询更改，然后使用 buildbot.schedulers.filter:Changefilter 与 Scheduler 结合来触发适当的构建。这是通过 autobot.changes.poller 中的 GitPoller 和 HgPoller 完成的。同样，根据需要可以添加更多轮询器，或者可以利用提供的 buildbot 更改来源。

虽然通常应该在类级别指定规范来源，但如果向 SourceFactory 构造函数传递了适当的参数（例如 hg 或 git），则将覆盖该来源类型。这对于在非规范 URL 和/或分支上测试更改非常有用。

添加新项目

偶尔，您需要添加新项目进行测试。您可以在 autobot.projects 下的目录中添加一个 __init__.py 文件，并且如果您在其中有一个工厂，autobot 将找到它并将其添加到它所知道的工厂列表中。

还有一个名为 create-autobot-project 的脚本，可以为您创建此占位符。

Usage: create-autobot-project [options] project <output>

project 是项目的名称，如果指定 output，则是要创建文件的路径。如果没有指定输出，它将找到其路径到 autobot.projects 下以项目命名的目录。

有几个工厂（BuildFactory 后代）位于 autobot.process 中，以便更容易地构建新项目。

• SourceFactory：如上所述，它处理源并提供了下载它们的方法（checkout()）。master.cfg 在每个工厂中查找，并从其 SourceFactory 的内部存储机制中的 sources 属性（如果有）中提取所需的存储库，并据此设置调度器。

• VirtualenvFactory：继承自 SourceFactory。创建一个 Python 虚拟环境，并提供构建属性 %(virtualenv)s、%(python)s 和 %(scripts)s（Unix 上的 bin 位置或在 Windows 上的 Scripts 位置，相对于虚拟环境）。它还有一个 findScript() 方法，该方法接受 Unix 风格的脚本名称（无扩展名）并返回平台上的脚本路径。

• PythonSourceFactory：继承自 VirtualenvFactory。它将所有源（目前是这样，但可以进行更改）视为 Python 包的源。除了在 %(virtualenv)s/src 中检出它们之外，它还会安装它们（使用 %(python)s setup.py install）。

请参阅 autobot.process.factory 文件以获取更多详细信息。这些类旨在作为混合（不是我最喜欢的模式，但似乎这是 buildbot 希望你做的事情）。需要做更多工作以支持更广泛的使用案例，但现有的内容被认为是“良好的开端”而不是“最终形式”。根据需要可能会添加更多工厂。

你的 autobot 是不是有点儿烦躁？

告诉我！我希望让 autobot 成为对所有利益相关者都适用的解决方案，如果你在读这个，那就意味着你！

k0scist@gmail.com

待办事项

没有软件是永远完成的。以下是我希望添加的一些内容

• 电子邮件通知

• 在奴隶上单一检出存储库：奴隶应有一个单一的主存储库，该存储库针对每个存储库 URL 和分支对检出一次。然后根据需要更新，例如从那里克隆。这应该有效地减少获取时间。