pythontox，创建rpm virtualenv，作为ci管道的一部分，不确定在哪里

Question

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

詹金斯被用来做最初的储存库克隆，然后启动毒物分析。基本上这就是maven和/或msbuild获取依赖包并构建的地方。。。。毒物是通过pip做的，所以这里一切都很好。在

但是现在对于令人困惑的部分，管道的最后一部分是创建和上传包。开发人员可能会将创建的包上载到本地pip存储库，但也可能创建部署包。在这种情况下，它需要一个包含应用程序虚拟化的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.测试，flake8，以及量角器和茉莉花测试）
• 如果tox步骤恢复正常，启动一个不同的docker容器来构建一个deb包
• 将deb包推到S3，让Salt处理通知这些机器更新的问题

这个deb包也只是作为构建工件提供的，类似于Jenkins 1.x所做的。一旦我们准备好进入登台阶段，我们只需将该包手动升级到登台debian回购。同样的，把它卷到prod上

我发现这些工具都很有用：

• Buildbot因为它是用Python编写的，因此对我们来说比较容易，但是Jenkins也可以。不管怎样，这是整个管道的控制器
• Docker，因为每个构建都应该与其他构建完全隔离
• 让光荣的试飞员处理所有这些细节
• fpm生成包。转速，德布，焦油gz不管怎样。非常可配置，易于编写脚本。在
• Aptly使管理debian存储库变得更加容易，尤其是将它们推到S3。在