避免/减少 Travis-CI 构建的多次安装答案

【问题标题】：Avoiding/reducing multiple installations for Travis-CI builds避免/减少 Travis-CI 构建的多次安装
【发布时间】：2015-02-04 07:38:47
【问题描述】：

对于 Jailhouse hypervisor 的 Travis-CI 构建，我们有一个相当昂贵的环境设置，其中包括部分分发更新以引入最近的 make 版本（>=3.82，默认版本仍然只有 3.81 - Ubuntu ...)、一个用于 ARM 的交叉工具链和一个 100 MB 的预构建 Linux 内核源程序包，我们需要这些源代码来编译一个树外模块。

为了减少构建时间和内核下载次数，我们目前在一次运行中按顺序构建所有配置变体（make; make clean; make...）。这对于检查构建损坏很好，但是添加了取决于构建输出的 Coverity 扫描，它不再起作用。切换到构建矩阵似乎是显而易见的解决方案，但代价是多次安装，因为 Travis-CI 似乎无法在此类构建期间重用它们。虽然我们目前只有 3 种配置变体，但未来会增加（例如，添加的每个 ARM 板都会增加一个），因此该方法并不能真正扩展。

我们有其他选择吗？我已经看过缓存，可通过基于 docker 的构建获得，但缺乏 sudo 支持阻止了这种方法。其他想法？

【问题讨论】：

标签： linux matrix travis-ci coverity jailhouse

【解决方案1】：

你应该改变你的构建来做到这一点

cov-build --idir <target1> make; make clean
...

为每个构建使用不同的中间目录。然后稍后返回并运行

cov-analyze --idir <target1>
cov-commit-defects --idir <target1> --stream <target1>

【讨论】：

嗯，这与标准 travisci_build_coverity_scan.sh 现在所做的不同。这些命令在该脚本中替换了什么，单个 cov-build 步骤？这些接口记录在哪里？它们有多稳定？我担心当 Coverity 改变他们的程序时，这可能会很快中断，至少对于 Travis-CI 来说是这样。不过，感谢您的指点！
没错，但你正在做一些非常不同的事情。您的构建正在构建和清理多次，因此您希望捕获每个构建。 Cov-build 用于捕获构建，cov-analyze 运行分析，cov-commit-defects 将缺陷放入 CIM。
越来越近：我们需要流来管理配置变体（如不同的目标架构或板）——但我们可能不会以OSS project 的形式获得它们。使用 Coverity 检查... PS：使用免费的基于云的扫描时，您没有本地分析（cov-analyze、cov-commit-defects）。
啊，是的，专业服务可能是谈论您需求的最佳人选。您可能还想查看 CodeSpotter。