python tox，创建 rpm virtualenv，作为 ci 管道的一部分，不确定工作流的位置

Question

我正在研究 Python 应用程序如何也可以使用 CI 管道，但我不确定如何创建标准工作流。

Jenkins 用于做初始仓库克隆，然后启动 tox。基本上这是 maven 和/或 msbuild 将获取依赖包并构建.... tox 通过 pip 执行的操作，所以在这里一切都很好。

但是现在对于令人困惑的部分，管道的最后一部分是创建和上传包。开发人员可能会将创建的包上传到本地 pip 存储库，但也可能会创建一个部署包。在这种情况下，它需要是一个包含应用程序 virtualenv 的 RPM。我已经使用 rpmvenev 手动制作了一个，但不管它是如何制作的，如何将这样的步骤添加到 tox 配置中？如果是 rpmvenv，它会创建自己的 virtualenv，可以说是一个自包含的命令。

Answer 1

我喜欢用 Unix 哲学来解决这个问题。拥有一个工具可以很好地完成一件事，然后将其他工具组合在一起。 Tox 是专门为在一堆不同的 python 环境中运行你的测试而构建的，所以用它来为你构建一个 deb / rpm / etc 我觉得有点滥用这个工具。使用 tox 来运行所有测试可能更容易，然后根据结果在管道中为刚刚测试的内容构建一个包的另一个步骤。

在撰写本文时，Jenkins 2.x 似乎是相当新的版本，它在构建管道方面似乎要好得多。 BuildBot 正在进行大量的开发，并且已经相当容易为此构建良好的管道。

我们在工作中所做的是

• AWS 中的 Buildbot 从 PR 上的 Github 接收推送通知
• 这会启动一个 docker 容器，该容器会拉入当前代码并运行 Tox（py.test、flake8 以及量角器和 jasmine 测试）
• 如果 tox 步骤恢复正常，请启动另一个 docker 容器以构建 deb 包
• 将该 deb 包推送到 S3 并让 Salt 处理告诉这些机器更新

该 deb 包也可以作为构建工件使用，类似于 Jenkins 1.x 所做的。一旦我们准备好进行登台，我们只需将该包手动升级到登台 debian 存储库。同上滚动它来刺激。

我发现对这一切有用的工具：

• Buildbot 因为它在 Python 中，因此我们更容易处理，但 Jenkins 也能正常工作。无论如何，这是整个管道的控制器
• Docker 因为每个构建都应该与其他构建完全隔离
• Tox 光荣的测试运行者来处理所有这些细节
• fpm 构建包。 RPM、DEB、tar.gz 等等。非常可配置且易于编写脚本。
• Aptly 可以轻松管理 debian 存储库，尤其是将它们推送到 S3。