合作伙伴重新打包

我们为一些额外的受众创建了略微修改的 Firefox 版本

  • 无 EME 版本，默认情况下禁用 DRM 插件

  • Funnelcake 版本，用于 Mozilla 实验

  • 合作伙伴版本，为外部合作伙伴定制 Firefox

我们使用“合作伙伴重新打包”这个短语来指代所有这些版本，因为它们都使用相同的流程将常规 Firefox 版本与其他文件重新打包。具体差异取决于版本的类型。

作为发布自动化的一部分，我们为一些 Beta 版本和发布版本生成合作伙伴重新打包版本。我们不生成任何文件来更新这些版本，因为它们是自动处理的（参见 更新）。

我们还生成 合作伙伴署名 版本，这些版本是添加了队列标识符的 Firefox Windows 安装程序。

参数 & 调度

合作伙伴重新打包有一些参数控制其工作方式

  • release_enable_emefree

  • release_enable_partner_repack

  • release_partner_config

  • release_partner_build_number

  • release_partners

我们将重新打包分为两个“路径”，无 EME 和其他所有内容，以保留一些单独启用/禁用它们的灵活性。这导致我们在重新打包堆栈中有一些类型的重复。这两个启用参数是布尔值，用于打开/关闭这两个路径。我们在 shipit 的 is_partner_enabled() 中设置它们，以开始发布。Firefox Beta 版本 >= b8 和发布版本都为真，但在其他情况下则禁用。

release_partner_config 是一个配置数据字典，它驱动任务生成逻辑。它通常在发布推广操作任务期间查找，使用 get_partner_config_by_url() 函数中的 Github GraphQL API，该函数的 url 定义在 taskcluster/config.yml 中。

release_partner_build_number 是一个整数，用于在 Firefox 候选目录中创建唯一的上传路径，而 release_partners 是一个应重新打包的合作伙伴列表（即整个配置的子集）。两者都旨在在常规 Firefox 发布后重新生成一些合作伙伴时使用。更多信息可以在 RelEng 文档 中找到。

生成合作伙伴重新打包版本的大部分机器时间发生在自动化的 promote 阶段，或者在 X.0 发布候选版本的情况下发生在 promote_rc 阶段。无 EME 版本与常规版本一起在 push 阶段复制到 Firefox 发布目录中。

配置

我们需要一些配置来了解什么要重新打包以及如何打包。什么由 default.xml 清单定义，正如 git 的 repo 工具所使用的那样。 无 EME 的 default.xml 说明了这一点

<?xml version="1.0" ?>
<manifest>
  <remote fetch="[email protected]:mozilla-partners/" name="mozilla-partners"/>
  <remote fetch="[email protected]:mozilla/" name="mozilla"/>

  <project name="repack-scripts" path="scripts" remote="mozilla-partners" revision="master"/>
  <project name="build-tools" path="scripts/tools" remote="mozilla" revision="master"/>
  <project name="mozilla-EME-free" path="partners/mozilla-EME-free" remote="mozilla-partners" revision="master"/>
</manifest>

repack-scripts 和 build-tools 仓库存在于所有清单中，然后是包含如何配置的合作伙伴仓库列表。其中一些仓库不公开可见。

合作伙伴仓库可以在 desktop 目录中包含多个配置。每个子目录必须包含一个 repack.cfg 和一个 distribution 目录，后者包含所需的自定义内容。这是 无 EME 的 repack.cfg

aus="mozilla-EMEfree"
dist_id="mozilla-EMEfree"
dist_version="1.0"
linux-i686=false
linux-x86_64=false
locales="ach af an ar"  # truncated for display here
mac=true
win32=true
win64=true
output_dir="%(platform)s-EME-free/%(locale)s"

请注意语言环境列表和用于启用平台的布尔切换。

所有自定义内容都将放置在 Firefox 安装目录根目录下的 distribution 目录中，或者在 OS X 的情况下放置在 Firefox.app/Contents/Resources/distribution/ 中。 distribution.ini 文件是最小要求，这是来自 无 EME 的示例

# Partner Distribution Configuration File
# Author: Mozilla
# Date: 2015-03-27

[Global]
id=mozilla-EMEfree
version=1.0
about=Mozilla Firefox EME-free

[Preferences]
media.eme.enabled=false
app.partner.mozilla-EMEfree="mozilla-EMEfree"

扩展和其他自定义内容也可能包含在重新打包版本中。

重新打包流程

创建合作伙伴重新打包版本的任务堆栈与本地化的每日构建和常规发布大致相似。基本形式是

  • 合作伙伴重新打包 - 将自定义内容插入常规构建中

  • 签名 - 签名将成为安装程序的内部文件（仅限 Mac）

  • 重新打包 - 创建“安装程序”（Mac 和 Windows）

  • 分块虚拟 - 仅限 Linux 的桥接至…

  • 重新打包签名 - 签名“安装程序”（主要是 Windows）

  • beetmover - 将文件移动到特定于合作伙伴的目标位置

  • beetmover 校验和 - 可能从上一步移动校验和

一些关键差异是

  • 所有中间工件都以 releng/partner 前缀上传

  • 我们不会在 Windows 上插入任何二进制文件，因此不需要内部签名

  • 在重新打包步骤中不需要创建任何完整的 mar 文件

  • 我们只需要为无 EME 版本创建 beetmover 校验和

合作伙伴重新打包

  • 类型：release-partner-repack release-eme-free-repack

  • 平台：通常所有平台（但取决于合作伙伴配置启用的内容）

  • 上游：build-signing l10n-signing

此步骤中每个平台都有一个任务，调用 mozharness 中的 scripts/desktop_partner_repacks.py 来准备环境，然后执行重新打包。实际的重新打包由 python/mozrelease/mozrelease/partner_repack.py 完成。

它将构建签名和 l10n 签名工件作为输入，这些工件都是 zip/tar.gz/tar.bz2 归档文件，通过避免 dmg 和 exe 简化了重新打包过程。Windows 生成 target.zip & setup.exe，Mac 是 target.tar.gz，Linux 是最终产品 target.tar.bz2（beetmover 像往常一样处理漂亮的命名）。

签名

  • 类型：release-partner-repack-mac-signing release-partner-repack-mac-notarization

  • 平台：Mac

  • 上游：release-partner-repack release-eme-free-repack

我们将单个合作伙伴重新打包任务分成 5 个工件的签名任务。例如，无 EME 将变为 19 个任务。我们从上游收集 target.tar.gz，并返回一个已签名的 target.tar.gz。我们对每日构建/常规发布使用 target.dmg 工件，但签名脚本工作程序在将其发送到签名服务器之前将其转换为 target.tar.gz，因此合作伙伴是等效的。mac-signing 任务对二进制文件进行签名，然后 mac-notarization 将其提交给 Apple 并将其票据钉在上面。

重新打包

  • 类型：release-partner-repack-repackage release-eme-free-repack-repackage

  • 平台：Mac & Windows

  • 上游

    • Mac：release-partner-signing release-eme-free-signing

    • Windows：release-partner-repack release-eme-free-repack

Mac 每个签名任务都有一个重新打包作业。Windows 重新打包在此处被分割成与 Mac 相同的粒度。将 target.zip & setup.exe 转换为 Windows 上的 target.exe，并将 target.tar.gz 转换为 Mac 上的 target.dmg。这里不需要像常规发布版本那样生成任何 complete.mar 文件，因为我们可以重复使用它们。

分块虚拟

  • 类型：release-partner-repack-chunking-dummy

  • 平台：Linux

  • 上游：release-partner-repack

我们需要在下一步对 Linux 进行分块，因此此虚拟任务负责 Linux 所遵循的相对简单的路径。每个子配置+语言环境组合一个任务，与 Windows 和 Mac 相同。无 EME 不需要它，因为我们不需要在那里创建 Linux 版本。

重新打包签名

  • 类型：release-partner-repack-repackage-signing release-eme-free-repack-repackage-signing

  • 平台：所有平台

  • 上游

    • Mac & Windows：release-partner-repackage release-eme-free-repackage

    • Linux：release-partner-repack-chunking-dummy

此步骤对所有平台进行 GPG 签名，并对 Windows 安装程序进行 Authenticode 签名。

Beetmover

  • 类型：release-partner-repack-beetmover release-eme-free-repack-beetmover

  • 平台：所有平台

  • 上游：release-partner-repack-repackage-signing release-eme-free-repack-repackage-signing

将工件移动并重命名到 候选目录 中的公共位置。每个任务都将具有 project:releng:beetmover:action:push-to-partner 和 project:releng:beetmover:bucket:release 范围。beetmoverscript 中有一个单独的合作伙伴代码路径。

Beetmover 校验和

  • 类型：release-eme-free-repack-beetmover-checksums

  • 平台：Mac & Windows

  • 上游：release-eme-free-repack-repackage-beetmover

不含 EME 的构建版本应该存在于我们的 SHA256SUMS 文件和其他相关文件中（例如 此处），因此我们将 beetmover 任务中的 target.checksums 移动到 candidates 目录。它们会被 release-generate-checksums 类型的任务捕获。

更新

很少需要以与原始发行版构建版本不同的方式更新合作伙伴重新打包版本，但我们保留了这种能力。一个基于 Firefox 发行版构建，且分发名称为 foo 的合作伙伴构建版本，将在 release-cck-foo 通道上查询更新。如果更新服务器 Balrog 未找到该通道的规则，它将回退到 release 通道。常规发行版的更新文件不会修改 distribution/ 目录，因此自定义内容不会被修改。

Bug 1430254 是此逻辑的例外情况示例。