部分更新生成

概述

Windows、Mac 和 Linux 版本都提供了部分更新，以减少最终用户需要下载的文件大小以获取新版本。这些更新是使用 Docker 镜像、一些 Python 代码、mbsdiff 以及 tools/update-packaging 中的工具创建的。

该任务在很长一段时间内被称为“Funsize”。这可能取决于您附近可获得的巧克力棒品牌。

任务的工作原理

Funsize 使用一个树内构建的 Docker 镜像，名为 funsize-update-generator。该镜像包含一些 Python 代码来检查任务定义并确定需要执行的操作，但它会从任务定义中指定的路径或默认的 mozilla-central 路径下载 mar 和 mbsdiff 等工具。

任务定义的“extra”部分包含大部分有效负载，位于“funsize”键下。这里列出了此特定任务将生成的补丁，每个条目都包含较早的（或“from”）版本和最新的（或“to”）版本，对于大多数版本来说，这很可能是一个 taskcluster 工件。

{
   "to_mar": "https://tc.net/api/queue/v1/task/EWtBFqVuT-WqG3tGLxWhmA/artifacts/public/build/ach/target.complete.mar",
   "product": "Firefox",
   "dest_mar": "target-60.0b8.partial.mar",
   "locale": "ach",
   "from_mar": "http://archive.mozilla.org/pub/firefox/candidates/60.0b8-candidates/build1/update/linux-i686/ach/firefox-60.0b8.complete.mar",
   "update_number": 2,
   "platform": "linux32",
   "previousVersion": "60.0b8",
   "previousBuildNumber": "1",
   "branch": "mozilla-beta"
 }

“更新编号”指示“to”和当前“from”之间有多少个已发布版本。例如，如果我们正在为当前的 nightly 版本从前一个版本构建部分更新，则更新编号将为 1。对于之前的版本，它将为 2。这使我们能够使用通用的输出工件名称，我们可以在之后的 beetmover 任务中重命名它们。

在任务内部，对于它被告知要生成的每个补丁，它将下载、解包并扫描“from_mar”和“to_mar”的病毒，下载工具，并运行 tools/update-packaging 中的 make_incremental_update.sh。

如果为一组临时 S3 凭据提供了作用域，则任务将使用缓存脚本，以允许重用为较大的文件生成的差异。一些较大的文件没有本地化，这使我们能够节省大量的计算时间。

用于版本发布

补丁作为 promote 任务组的一部分生成。用于创建更新的先前版本由发布管理在 ship-it 中指定。

Nightly 版本的补丁

由于 nightly 版本不会出现在 ship-it 中，因此要创建的补丁在决策任务中确定。这曾引发争议，因此以下列出了假设和原因，以便在发现替代解决方案时，我们可以在上下文中对其进行评估。

  1. Balrog 是先前 nightly 版本的事实来源。

  2. 重新运行任务应产生相同的结果。

  3. 任务的输入和输出应在定义中指定。

  4. 任务转换应避免外部依赖项。这是为了增加“mach taskgraph”有效的场景数量。

  5. 任务图不会明确知道它是为 nightly 版本设计的，只知道某些特定任务仅存在于 nightly 版本中。

  6. 决策任务使用 target-tasks-method 参数明确告知其目标是 nightly 版本。

  1. 根据 2 和 3，这意味着补丁任务本身无法查询 Balrog 以获取历史记录，因为它在重新运行时可能会得到不同的结果，并且会隐藏任务定义中的输入和输出。

  2. 根据 4，“mach taskgraph”运行的任何内容都不适合查询 Balrog，即使它导致可重复的任务图也是如此。

  3. 由于这些限制不适用于决策任务，并且鉴于 6，如果给定的 target-tasks-method 包含“nightly”（例如“nightly_desktop”或“nightly_linux”），我们可以在决策任务中查询 Balrog。

使用决策任务涉及对 Balrog 发出更少、更大的查询，并存储结果以供任务图重新生成和以后审核。目前，这些数据存储在 parameters 中，标签为 release_history，因为参数是将数据传递给任务转换的现有方法，但可以为添加单独的存储提出论点，因为它比参数中的任何其他内容都包含大量记录。

Nightly 版本的补丁和 Beetmover

特定平台和语言环境的版本可能没有可用于构建部分更新的先前版本的历史记录。这可能是由于各种原因造成的，例如新的语言环境或 nightly 版本的中断导致历史记录中出现过长的间隙。

这意味着 partials 和 partials-signing 任务可能对某个平台和语言环境没有作用。如果属实，则这些任务将在 transform 中被过滤掉。

这确实意味着下游任务 beetmover-repackage 无法依赖于 partials-signing 任务的存在。它依赖于 partials-signing 和 repackage-signing 任务，并在 transform 中选择要依赖的任务。

如果 parameters 的 release_history 部分存在历史记录，则 beetmover-repackage 将依赖于 partials-signing。否则，它将依赖于 repackage-signing。

这不是理想的，因为它会导致任务图生成中出现不清楚的逻辑。这将得到改进。