anybox.buildbot.openerp 0.9

Buildbot从软件

对于奴隶软件本身，只需遵循官方buildbot的做法

virtualenv buildslaveenv
buildslaveenv/bin/pip install buildbot-slave
bin/buildslave create-slave --help

系统构建依赖关系

奴隶主机系统必须具有运行可用构建out的所有构建依赖项。实际上，可能需要从pypi安装所需的python eggs，这可能会触发一些编译。反过来，这些通常需要构建实用工具（gcc、make等）、库和头文件。

有基于debian系统的软件包，可安装OpenERP构建out所需的所有依赖项。

注册和从能力

请将您的奴隶注册到主管理员，指定可用的PostgreSQL版本（例如，8.4、9.0），如果有特殊构建使用了它们，请指定其他能力。有关Postgresql能力属性的详细信息，请参阅下文“PostgreSQL要求”。

最好提供slaves.cfg片段（有关语法和受支持的选项，请参阅slaves.cfg.sample）。

能力定义为slaves.cfg选项，每行一个能力和版本对。每行以额外的能力属性结束

[my-slave]
capability = postgresql 8.4
             postgresql 9.1 port=5433
             private-bzr+ssh-access
             selenium-server 2.3

能力用于

• 过滤：仅在能够执行构建的构建上运行（请参阅build-requires选项）

• 从节点本地条件：通过构建属性和环境变量应用依赖于从节点（此处为PostgreSQL 9.1的端口）的参数。默认情况下，所有内容都已针对postgresql功能进行调整，但高级用户可以在master.cfg中注册环境变量映射以供其他功能使用。

• 解复用：这是MANIFEST.cfg中的build-for选项。

上面的示例演示了如何使用它来指示访问某些私有仓库，假设主节点的MANIFEST.cfg声明了需要此访问的构建。

build-requires=private-bzr+ssh-access

在某些情况下，进一步限制从节点只运行真正需要的构建是有意义的。这对于稀有或昂贵的资源很有用。以下是一个示例slave.cfg提取。

[mybuildslave]
build-only-if-requires=selenium

PostgreSQL需求和能力声明

当然，您必须提供一个或多个有效的PostgreSQL安装（集群）。这些在配置文件中被描述为能力，使主节点了解您的从节点以及如何在上面运行构建。

默认值假设从节点系统上的标准PostgreSQL集群，PostgreSQL用户与运行从节点的POSIX用户具有相同的名称，并具有数据库创建权限。假设从节点的POSIX用户是buildslave，只需这样做：

sudo -u postgres createuser --createdb --no-createrole \
     --no-superuser buildslave

或者，您也可以提供主机、端口和密码（查看slaves.cfg文件以了解如何在主配置中表达）。

警告：目前，设置用户/密码不受支持。只有Unix套接字域将工作（见下文）。

基于Debian的分发版默认的主机空白值将使从节点通过Unix域套接字连接到PostgreSQL集群，即用户名与运行从节点的POSIX用户相同。默认PostgreSQL配置允许这种连接无需密码（在pg_hba.conf中使用ident认证方法）。

要在辅助或自定义编译的集群上使用ident认证，我们提供了额外的能力属性

• bin和lib应指向集群的可执行文件和库目录。否则，构建可能会使用错误的客户端库版本运行。

• 如果postgresql.conf中设置了unix_socket_directory，则将其作为host能力属性提供。否则，如果bin和lib正确（见上文），则psql可执行文件和客户端库将使用与服务器相同的默认值。

• 如果不使用默认的5432端口，您必须提供端口号，因为端口唯一标识集群，即使对于Unix域套接字也是如此。

示例

# Default cluster of a secondary PostgreSQL from Debian & Ubuntu
capability postgresql 9.1 port=5433

# Compiled PostgreSQL with --prefix=/opt/postgresql,
# port set to 5434 and unix_socket_directory unset in postgresql.conf
capability postgresql 9.2devel bin=/opt/postgresql/bin lib=/opt/postgresql/lib port=5434

# If unix_socket_directory is set to /opt/postgresql/run, add this:
# ... host=/opt/postgresql/run

自定义构建

有一个钩子可以替换构建out（测试运行，然后日志分析）之后的步骤，由自定义步骤替换。这是一个高级选项，旨在为了解anybox.buildbot.openerp内部结构以及它设置和使用的属性的用戶使用。

在主配置文件中，注册一个返回构建bot步骤列表的可调用函数。不要调用configure_from_buildouts，而是按照以下示例进行操作：

from anybox.buildbot.openerp.configurator import BuildoutsConfigurator
configurator = BuildoutsConfigurator(basedir)
configurator.post_buildout_steps['mycase'] = mycase_callable
configurator.populate(BuildmasterConfig)

其中mycase_callable通常是具有与BuildoutsConfigurator的post_buildout_steps_standard方法相同签名的函数。这意味着它可以读取选项字典，因此可以对其自己的选项做出反应。

然后，在MANIFEST.cfg文件中报告相关的mycase名称，在相关构建配置的章节中。

[mybuildout]
post-buildout-steps = mycase
...

标准的构建是通过standard键来实现的。您实际上可以通过在配置选项中指定多个此类键（每行一个）来链式使用它们。以下是一个实际生活中的例子。

[mybuildout]
post-buildout-steps = static-analysis
                      standard
                      doc

目前，standard是唯一的内置后构建步骤集合。

待办事项：提供更多内置的后构建步骤集合；将文档分为两部分，第一部分列出它们并解释如何在配置中使用它们，第二部分解释如何注册自定义的步骤。第一部分文档不需要对buildbot或anybox.buildbot.openerp有内部知识。

能力自定义环境映射

如上所述，能力系统可以根据所选的构建版本和能力版本设置环境变量。当然，如果测试本身直接或间接地使用了这些变量，这将非常有用。

环境映射仅预设了postgresql，以下是如何为另一个能力注册一些映射的示例，从master.cfg。同样，这通过配置对象的实例化来分步执行，而不是通过configure_from_buildouts辅助函数。

abo_conf = BuildoutsConfigurator(basedir)
abo_conf.add_capability_environ(
    'rabbitmq',
    dict(version_prop='rabbitmq_version',
         environ={'RMQ_BASE_URI': '%(cap(base_uri):-)s'),
                  'RMQ_BINARY': '%(cap(binary):-)s'),
                  'AMQP_CTL_SUDO': '%(cap(sudo):-TRUE)s'),
      }))

abo_conf.populate(BuildmasterConfig)

现在，在从属服务器上以这种方式定义了rabbitmq能力。

rabbitmq 2.8.4 base_uri=amqp://guest:guest@localhost:5672/ binary=rabbitmqctl sudo=True

这将设置RMQ_BASE_URI、RMQ_BINARY和AMQP_CTL_SUDO到这些值。

在environ子字典中的值是WithProperties语句，具有它们的全部表达能力；只需注意添加了cap(option_name)的语法来引用与能力选项相对应的属性。

调整、优化和陷阱

• 蛋和openerp下载是在每个从属服务器上共享的。一个锁系统防止构建运行时的并发性。

• 目前不支持Windows从属服务器：一些步骤在参数中使用‘/’分隔符。

• 不要在虚拟环境“激活”时启动从属服务器；同时注意，虚拟环境的bin/目录必须不在POSIX用户默认的PATH上。许多构建步骤不是为此设计的，并且可能会缺少一些依赖项。这特别是对于构建步骤的情况。

• 如果您想添加基于虚拟环境的构建工厂，如http://buildbot.anybox.fr（特别是这个分布）中找到的，请确保默认系统Python有virtualenv >=1.5。旧版本在/tmp中硬编码文件名，这会导致在以不同的系统用户运行virtualenv时出现权限错误（这意味着在从属服务器上调用virtualenv的任何调用都将破坏需要它的从属服务器上的后续构建）。特别地，请注意，在Debian 6.0（Squeeze）中，python-virtualenv目前是1.4.9，并且不在squeeze-backports中。您必须手动设置它（首先安装python-pip）。

0.9 (2015-05-15)

• Git支持（构建bout仓库+监视）（launchpad上有多个问题）

• launchpad #1201138：简单的继承系统

• launchpad #1201175：自动监视VCS构建输出自身（而非其引用的内容）

• 添加了一个“静态分析”构建输出子工厂

• launchpad #1201099：引入子工厂以实现更清晰的插件化

  （构建输出后的步骤等）

• launchpad #1196310：提供“构建输出后步骤”以进行功能测试

• launchpad #1196308：提供“构建输出后步骤”以进行nose测试

• launchpad #1198702：在MANIFEST中提供引导选项

• launchpad #1142994：VCS轮询的URL重写

• launchpad #1154673：treeStableTimer调度器参数现在可以按构建输出进行配置

• launchpad #1281136：为Sphinx文档编译和上传提供子工厂

• launchpad #1281137：为hg版本化构建输出提供打包子工厂

0.8.1

• launchpad #1130838：仅当需要时构建的buildslave选项

• 使用anybox.recipe.openerp 1.2提供的统一测试启动脚本

• launchpad #1086066：检测unittest2失败和错误

• launchpad #1086392：通过逐个重试分支来提高对缺少远程mercurial分支的恢复力

• 为构建输出和测试提供替代的下载步骤（允许打包和测试打包的内容）

• 使用hgtag构建输出源从属性中指定的标签读取

• 质量：flake8合规性

0.7

• launchpad #999069：现在可以自定义构建工厂的构建工厂部分测试运行

• launchpad #1040070：可以读取多个MANIFEST文件

• launchpad #1050842：现在独立构建输出路径相对于manifest目录是相对的

• db_template构建输出选项。

• launchpad #999066：用于在范围内查找空闲端口的实用脚本

• 忽略bzr分支拉取中的差异（特别是对于镜像）

0.6

• launchpad #1008985：现在可以从VCS直接检索构建输出（目前仅限Mercurial）。

• launchpad #1004844：通过能力调度PostgreSQL版本，允许在单个从属节点上构建多个版本。

• launchpad #999116：按能力过滤给定构建工厂（构建输出）的从属节点。

• launchpad #1004916：从属节点max_builds和notify_on_missing

  现在考虑参数

0.5

• 使用OpenERP配方中的vcs-clear-retry选项

• launchpad #994524：“构建为”配置选项允许指定PostgreSQL版本范围

• launchpad #998829：在MANIFEST.cfg中添加新的build-category选项

0.4.4

• 现在可以根据构建工厂指定要安装的插件列表

0.4.3

• 文档改进

0.4.2

• 文档改进

0.4.1

• 在pypi上的首次发布