openSUSE:构建服务概念后端 Worker API
摘要
目前，构建系统存在调用代码在 worker/本地构建中被中断以执行特殊处理的情况。这些代码本身不属于目标操作系统和架构，因此这些软件包不应位于目标仓库/架构中，也不应从目标仓库/架构中安装。
用例
在以下章节中，首先基于用例描述新的 Worker API，以便了解我们需要这个新 API 的原因以及您可以使用它做什么。
Worker 分配
应该有一种可配置的方法，根据机器的功能、架构或其他参数将任务分配给 worker。这应该成为新 API 的一部分。例如，worker 设置不仅应该可以通过回调拦截，worker 分配也应该可以通过回调拦截。
镜像
让我们从 kiwi-inside-obs 代码的最新更改开始。现在 worker 使用 build 而不是主机系统。这很好，但这里有一些副作用：我基本上使用 Base:build、busybox 和更多库来构建一个迷你发行版。在更改之前，worker 使用主机上的 kiwi，效果还可以。现在我没有所需的依赖项（kiwi、createrepo、python、sqlite、...）在我的小仓库中。它们必须位于“image”仓库内，并且“image”也需要从最顶层仓库派生（如果仓库是派生/堆叠的）。由于 kiwi 在自己的 chroot 中执行镜像，因此可以将 kiwi 包及其依赖项从 11.0 获取。这将使即使对于没有 kiwi 本身的仓库，或者使使用较新的 kiwi 变得非常容易，也能进行镜像。
考虑到 cross-kiwi，对于这种情况来说，这是强制性的，因为 kiwi-chroot 必须位于 $HOSTARCH 中。
结论是，需要使 kiwi-chroot 独立于用于镜像的仓库。
Worker 中的交叉构建和虚拟化
现在考虑使用 XEN-worker 进行交叉构建：要在 XEN-worker 内部使用 qemu-user-mode，需要一个最小的系统加上 qemu 在 $HOSTARCH (!) 中才能启动 XEN-VM。第一步是注册 qemu-binfmt-magic。所有其他软件包然后可以为 $TARGETARCH，因为 user-mode 处于活动状态。这意味着：预安装（和 Vminstall）加上 qemu 必须从 $HOSTARCH 获取，而不是从构建软件包的仓库/架构中获取。这是 Martin 和 worker-api 的位置；)，但基本上是与上述相同的过程。
build/baselibs.conf
目前，baselibs 支持由 OBS worker 或目标操作系统软件包中的特殊处理提供。可以删除这种特殊处理，并以与 qemu 预处理或 image/KWI 处理相同的方式完成。因此，不再需要从 worker 主机操作系统/架构直接调用目标仓库/架构代码。
rpmlint
与 build/baselibs.conf 案例类似的是使用 rpmlint 检查器来检查构建结果。它像 build/baselibs.conf 一样具有自己的可选配置文件。 同样，首先安装一个额外的软件包 rpmlint。 同样，在构建结果之后，执行一些操作。
测试框架
另一个与上述类似的应用是调用一个独立于软件包中执行的测试的测试框架。这可以是更“静态”的分析，例如 rpmlint（实际上也检查编译消息）或使用软件包执行的运行时测试（例如 ABI 测试、一致性测试）。
build-compare
构建迭代器“build-compare”是另一个构建后回调的示例。
构建后清理
存在一些修改构建环境并提供诸如挂载之类的设置的软件包，即使使用虚拟机，这些设置也未被自动 worker 清理完全识别。可以通过新方法调用这些额外的清理处理程序。
构建前设置
并非所有构建前设置都可以自动完成，甚至对某些情况（例如镜像）来说也没有用。当前的虚拟机设置可能过于严格，或者对于特定情况来说过于有限。
功能
后端 Worker API 解决方案
上述所有用例都有一个共同点。当前应用的特殊硬编码处理是 worker 主机设置缺少除了正常的 target OS worker chroot 设置之外的表达。 共同的解决方案是
- 可以从 worker chroot 内的软件包中安装主机软件包代码
- 回调可以在 chroot 或虚拟机或模拟器启动之前拦截执行
- 回调可以在 worker 完成后并在将结果返回给后端之前拦截执行
这种方法允许动态更改当前硬编码的行为，并以项目特定方式更改行为。