如何在公司中扩展构建机器人

发布于 2024-07-29 17:02:47 字数 243 浏览 2 评论 0原文

我最近一直在研究 buildbot,由于缺乏良好的文档和示例配置,因此很难理解 buildbot 的常用方式。

根据 buildbot 手册,每个 buildmaster 负责 1 个代码库。 这意味着想要在 10 个项目上使用 buildbot 的公司需要维护 10 套不同的 buildbot 安装(主从配置、开放端口、具有输出的网站等)。 这真的是做事的方式吗? 我是否缺少创建易于维护和监控的混搭的选项?

谢谢!

I've been looking into buildbot lately, and the lack of good documentation and sample configurations makes it hard to understand how buildbot is commonly used.

According to the buildbot manual, each buildmaster is responsible for 1 code base. That means that a company that wants to use buildbot on, say, 10 projects, needs to maintain 10 different sets of buildbot installations (master-slaves configurations, open ports, websites with output etc.). Is this really the way things are done? Am I missing an option that creates a mash-up that is easy to maintain and monitor?

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

与君绝 2024-08-05 17:02:47

在我的工作场所,我们使用 Buildbot 在多种架构和 Python 版本上测试单个程序。 我使用一名构建大师来监督大约 16 个奴隶。 每组从站从不同的存储库中提取数据并针对 Python 2.X 进行测试。

根据我的经验,配置单个构建主机来运行项目的混搭是很容易的。 这可能不是一个好主意,因为瀑布页面(构建从站报告结果的地方)可能会因为多个从站而变得非常拥挤。 如果您可以轻松地滚动较长的瀑布页面,那么这将不是问题。

编辑:

master.cfg 中的更新命令:

test_python26_linux.addStep(ShellCommand, name = "update pygr",
    command = ["/u/opierce/PygrBuildBot/update.sh","000-buildbot","ctb"], workdir=".")

000-buildbot 和 ctb 是附加参数,用于指定从哪个分支和存储库获取信息。 update.sh 脚本是我为了避免不相关的 git 问题而编写的。 如果您想运行不同的项目,您可以这样写:

builder1.addStep(ShellCommand, name = "update project 1",
    command = ["git","pull","git://github.com/your_id/project1.git"], workdir=".")

 (the rest of builder1 steps)

builder2.addStep(ShellCommand, name = "update project 2",
    command = ["git","pull","git://github.com/your_id/project2.git"], workdir=".")

(the rest of builder2 steps)

这两个项目不必相关。 Buildbot 为每个构建器创建一个目录并运行该目录中的所有步骤。

At my place of work we use Buildbot to test a single program over several architectures and versions of Python. I use one build master to oversee about 16 slaves. Each set of slaves pulls from a different repo and tests it against Python 2.X.

From my experience, it would be easy to configure a single build master to run a mash-up of projects. This might not be a good idea because the waterfall page (where the build slaves report results) can get very congested with more than a few slaves. If you are comfortable scrolling through a long waterfall page, then this will not be an issue.

EDIT:

The update command in master.cfg:

test_python26_linux.addStep(ShellCommand, name = "update pygr",
    command = ["/u/opierce/PygrBuildBot/update.sh","000-buildbot","ctb"], workdir=".")

000-buildbot and ctb are additional parameters to specify which branch and repo to pull from to get the information. The script update.sh is something I wrote to avoid an unrelated git problem. If you wanted to run different projects, you could write something like:

builder1.addStep(ShellCommand, name = "update project 1",
    command = ["git","pull","git://github.com/your_id/project1.git"], workdir=".")

 (the rest of builder1 steps)

builder2.addStep(ShellCommand, name = "update project 2",
    command = ["git","pull","git://github.com/your_id/project2.git"], workdir=".")

(the rest of builder2 steps)

The two projects don't have to be related. Buildbot creates a directory for each builder and runs all the steps in that directory.

心奴独伤 2024-08-05 17:02:47

仅供参考,BuildBot 0.8.x 支持一个主机上的多个存储库,稍微简化了一些事情。

FYI, BuildBot 0.8.x supports several repositories on one master, simplifying things a bit.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文