openSUSE:构建服务概念质量保证
如何使质量保证成为帮助而不是负担？
当质量保证检查在您认为工作已经完成很久之后才发现问题时，没有什么比这更令人恼火的了。因此，这意味着所有可能的质量保证应该尽快运行，并且立即在开发人员正在查看的地方可见。这通常是构建结果，无论是监控概述还是通知。
它还应该提供直接有用的信息，例如具体的错误消息、堆栈跟踪等，以最大限度地减少设置自己的开发系统的需要。
质量保证框架
这个概念不应该发明自己的质量保证框架，而是专注于集成所有可能的现有框架。
因此，OBS需要具有简单的SUCCESS/ERROR（可能还有WARNING）结果处理，以便生成简单的概述，但仍然能够显示所有类型的（以及可能的扩展的）质量保证框架结果。这可以是简单的文本文件，也可以是二进制文件，例如核心文件，甚至是完整的虚拟机快照。
在这个概念中，试图避免更复杂的状态，例如“预期失败”，并将其归属于下面使用的质量保证框架。
要集成的质量保证框架
- 随源代码一起提供的测试套件。
在rpm规范文件中，应使用%check部分来运行它们。
- 外部测试套件
- 如Testopia中所述的手动测试场景！
- 打包的测试套件
...（待完成）
质量保证测试类型
对于OBS处理来说，何时何地运行质量保证检查非常重要。从长远来看，我们应该支持以下情况
- 在编译时 => 完整的构建树仍然可用
- 打包后立即 => 构建的软件包已安装到构建环境中。可能已经安装了额外的软件包来运行质量保证。构建树可能仍然可用。
- 软件堆栈跟踪 => 已完成构建的一组软件包被安装到定义的环境中。不再有构建时的数据。
- 产品镜像已构建 => 应该在虚拟机（也可能是模拟的，例如使用QEMU）内运行自动化安装。
- 网络设置 => 多个虚拟机设置（无论是通过软件包还是通过镜像）需要能够交互。
- 硬件特定设置 => 为了测试特定的硬件支持或运行基准测试，需要相同的定义的硬件系统。无论是测试驱动程序还是使基准测试可比。
- 硬件特定设置的自动化软件更新 => 为了测试特定的硬件支持（与构建系统硬件不同），需要自动化的软件更新（例如，自动刷新或从生成的镜像通过网络启动）。这还包括仅更新已更改的软件包的自动化更新。（可选）
- 硬件特定设置的自动化测试控制 => 对于硬件特定设置，OBS应该处理测试控制，当测试在不同环境中运行时 - OBS需要处理连接、测试控制和电源控制（例如，在实验内核软件卡住时重新启动并继续）。
注意：应用构建可以像一个软件包一样处理，该软件包在构建后立即执行。但仅限于可以直接在我们的虚拟机中运行的应用。
将质量保证测试与代码连接
质量保证检查应该是可重用的，最好只在一个地方维护并在OBS中到处重用。质量保证检查可能适用于
- 所有软件包或镜像（应用或产品）
- 一组定义的软件包或镜像
- 特定的软件包，但在多个项目中
- 仅在特定项目中针对特定软件包
因此，质量保证检查可以定义它应该运行哪些软件包。一些例子
- 始终，在整个OBS中的所有构建中
- 在openSUSE:Factory中的所有软件包中运行。
- 运行所有在构建要求中具有gcc-c++的软件包
需要某种管理员授权才能创建这些定义。
另一方面，软件包或项目可以从随机位置选择一组质量保证检查。
在任何情况下，当软件包被派生到另一个位置时（例如，分支或链接软件包源代码），相同的质量保证检查应该默认运行。
潜在的工作流程
这是用于测试单个软件包构建的。我们需要一些额外的流程来测试产品。
对于这个例子，我们使用“bzip2”。
- 构建bzip2软件包
- 构建qa_bzip2
- 构建服务需要某种方式来知道它还需要构建qa_bzip2
- 要么我们在qa_bzip2内部将bzip2添加为BuildRequires，要么我们扩展OBS
- 构建完成后安装qa_bzip2软件包（在与构建相同的虚拟机或chroot上）
- 我们需要满足Requires依赖项（libbz2-devel、ctcs2等）
- 构建脚本执行一些“build-qa”脚本
- 此脚本需要了解如何运行ctcs2（或其他）测试并运行它们
- 处理结果并输出构建服务可以使用的内容
- 构建服务获取结果并存储/报告它们
- 总体聚合测试结果：SUCCEEDED/FAILED/SKIPPED
- 每个单独的测试用例：PASSED/FAILED
- 构建可以成功，但测试可能会失败
- 我们可以在构建服务上显示总体测试结果（成功/失败/跳过），然后在测试日志中显示特定结果
.QA 文件
我们需要一个.qa文件吗？到目前为止，我们认为我们可以避免它，只需打包质量保证检查并运行某个目录中的所有可执行文件。我们可能稍后需要添加一个来描述如何运行某个应用以及如何检查它。
打包带有任何依赖项的可执行质量保证检查对于开发人员将其安装到开发环境中并在提交软件包到构建系统之前运行检查很有用。
使质量保证结果的差异可见
实施概念
示例设置
1) 是一个项目源链接，它将所有质量保证软件包链接到目标项目，以便重建和运行它们。软件包仅在测试套件仓库中构建和运行。 2) 是一个软件包源链接，只是通过分支调用链接要修改的软件包
质量保证检查可以来自QA:Head项目中的自己的专用软件包或来自openSUSE:*软件包源的上游来源。
未解决的问题
- 如何仅对一个仓库启用/禁用项目链接源的软件包构建？
- 依赖于仓库名称规范？
- 通过自己的软件包构建类型和仓库标志（rpm-qa或deb-qa）来完成吗？
- 如何运行与上游源代码一起提供的质量保证检查，而与构建无关？
- rpmbuild可以跳过%check吗？
- 我们可以在之后运行它并避免%clean部分吗？
- 如何处理deb？
- 如何查找与特定软件包相关的所有质量保证结果？
- 检查与特定属性匹配的所有软件包？
- 检查所有使用标准仓库中的任何本地软件包的质量保证构建？
待定义
这需要由构建服务团队定义
- 如何将质量保证状态与构建结果分开报告
- 定义质量保证检查可以导出任何格式的测试结果的目录。传输回repo服务器并由api下载。