发布推广动作¶

发布推广动作是 Releng 如何触发发布推广 taskgraphs 的方式。一个动作涵盖所有发布推广需求：不同的“风格”允许我们为每个产品触发不同的发布推广阶段。输入模式和发布推广风格在发布推广动作中定义。

雪人模型¶

发布推广动作允许我们将多个 taskgraphs（也称为 graphs 或任务组）链接在一起。从本质上讲，我们使用优化逻辑用先前 taskgraph 中的任务 ID 替换当前 taskgraph 中的任务标签。

这就是“雪人”模型。如果您请求雪人的身体并指向底部，我们只会创建雪人的中间部分。如果您请求雪人的身体并且没有指向底部，我们将从头开始构建雪人的第一个底部和身体。

例如，让我们生成一个依赖于 t1 的任务 t2。让我们将新的 taskgraph 称为 G

G
|
t1
|
t2

任务 t2 将等待任务 t1 完成，并从任务 t1 下载一些工件。

现在让我们指定任务组 G1 和 G2 作为先前任务组 ID。如果任务 t1 位于其中一个任务组中，t2 将依赖于该任务，而不是在任务组 G 中生成新的 t1

G1        G2        G
|         |         |
t1        t1        |
            \______ |
                   \|
                    t2

or

G1        G2        G
|         |         |
t1        t0        |
  \________________ |
                   \|
                    t2

更真实的例子

     G
     |
   build
     |
  signing
     |
l10n-repack
     |
l10n-signing

如果我们将 promote 任务组 G 指向 on-push 构建任务组 G1，则 l10n-repack 作业将依赖于先前完成的构建和构建签名任务

   G1            G
   |             |
 build           |
   |             |
signing          |
       \_________|
                 |
            l10n-repack
                 |
            l10n-signing

我们还可以明确排除某些任务不被优化。我们目前通过在动作中指定 rebuild_kinds 来实现；这些是我们希望在当前任务组中显式重新构建的“种类”，即使它们存在于先前的任务组中。我们还允许指定一个 do_not_optimize 标签列表，这比指定要重建的种类更冗长和具体。

发布推广动作机制¶

在发布推广动作中定义了许多输入。其中包括 previous_graph_ids，它是一个有序的 taskGroupIds 列表，表示我们希望在其基础上构建任务组的任务组。在雪人模型中，这些定义了雪人已经构建的部分。

该动作从初始的 previous_graph_id 下载 parameters.yml，该 ID 与决策或动作任务 ID 匹配。（参见 taskid vs taskgroupid。）这很可能是要推广的修订版的决策任务，通常与运行发布推广动作的修订版相同。

注意

如果参数自构建以来已更改，并且我们明确希望发布推广动作任务使用新参数，则第一个 previous_graph_id 应为新修订版的决策任务。然后可以跟随构建和其他先前的动作任务组 ID，因此我们仍在用原始修订版中的任务 ID 替换任务标签。

然后，该动作从每个先前的任务组下载各种 label-to-taskid.json 工件，并构建一个 existing_tasks 参数，指示哪些标签需要替换为哪些任务 ID。对该字典的每次后续更新都会用新的任务 ID 覆盖现有的键，因此具有给定标签的最右侧任务组优先。任何与 do_not_optimize 列表匹配或属于 rebuild_kinds 列表中任务的标签都将从 existing_tasks 参数中排除。

一旦所有这些操作都完成，并且我们从原始参数、动作配置和输入中获得了配置，我们就会使用自定义参数运行决策任务函数。优化阶段将任何 existing_tasks 替换为我们从先前的任务组构建的任务 ID。

发布推广风格¶

在大多数情况下，发布推广风格匹配模式 phase_product，例如 promote_firefox、push_devedition 或 ship_firefox。

我们添加了 _rc 后缀风格，以处理围绕使用不同速率或渠道推出更新的特殊 RC 行为。

我们计划添加 _partners 后缀风格，以允许在周期外创建合作伙伴重新打包。

各种风格在发布推广动作中定义。

通过 Treeherder 触发发布推广动作¶

目前，我们可以通过 Treeherder 触发此动作；我们有时出于测试目的使用此方法。这很强大，因为我们可以直接修改输入，但不太适合生产环境，因为它要求我们手动输入输入。在某些时候，我们可能会禁用通过 Treeherder 触发动作的功能。

这需要使用正确的范围登录。在发布推广项目中，给定修订版的右上角有一个下拉菜单。选择 自定义推送动作，然后选择 发布推广。输入可以在左侧列中以原始 yaml 格式指定。

发布推广动作 taskId 和 taskGroupId¶

发布推广动作任务的 taskGroupId 将与决策任务的 taskId 相同。

发布推广任务组的 taskGroupId 将与发布推广动作任务的 taskId 相同。

所以

对于给定的推送，决策 taskId D 将创建 taskGroupId D
我们创建了一个发布推广动作任务，其 taskId 为 A。任务 A 将是任务组 D 的一部分，但会生成一个 taskGroupId 为 A 的任务组。

另一种看待方式

如果您查看动作任务组中的任务 t1，则 t1 的 taskGroupId 为动作任务的 taskId。（在上面的示例中，这将是 A。）
然后，如果您查看动作任务的 taskGroupId，则该 ID 为原始决策任务的 taskId。（在上面的示例中，这将是 D。）

测试和开发发布推广动作¶

要测试发布推广动作，我们可以使用 ./mach taskgraph test-action-callback 进行调试。

用于 promote_firefox 测试的完整命令可能如下所示

./mach taskgraph test-action-callback \
    --task-group-id LR-xH1ViTTi2jrI-N1Mf2A \
    --input /src/gecko/params/promote_firefox.yml \
    -p /src/gecko/params/maple-promote-firefox.yml \
    release_promotion_action > ../promote.json

输入文件（在上面的示例中，为 /src/gecko/params/promote_firefox.yml）包含动作输入。输入模式在发布推广动作中定义。以前的示例输入嵌入在先前的推广任务组动作任务定义中 (task.extra.action.input)。

可以从先前的决策或动作任务下载 parameters.yml 文件。