参数¶
任务图生成以 JSON 或 YAML 文件的形式将一系列参数作为输入。
在决策任务处理期间,其中一些参数通过命令行或环境变量提供。决策任务会很有帮助地生成一个完整的参数文件作为其输出工件之一。其他 mach taskgraph
命令可以将此文件作为输入。这在修改任务图时非常有用。
在试验任务图生成的本地运行时,始终最好找到最近决策任务的 parameters.yml
文件,并在必要时修改该文件,而不是从头开始。这确保您拥有完整的一组参数。
此处描述了参数对象的属性,大致按主题划分。
推送信息¶
android_perftest_backstop
此推送是否为 Android 性能测试的“后备”推送。也就是说,所有 Android 性能测试都应该在此推送中运行,以确保不会意外错过回归。
backstop
此推送是否为“后备”推送。也就是说,所有构建和测试都应该在此推送中运行,以确保不会意外错过回归。
base_repository
进行初始克隆的代码库,利用任何可用的缓存。
head_repository
包含要构建的变更集的代码库。在
base_repository
可能被缓存且只需要从head_repository
获取几个额外提交的情况下,这可能与base_repository
不同。base_rev
在
head_rev
合并之前的前一个版本。这可以是一个简短的版本字符串。head_rev
要检出的版本;这可以是一个简短的版本字符串
base_ref
将
head_rev
合并到的引用。它通常是分支或标签。head_ref
对于 Mercurial 代码库,这与
head_rev
相同。对于 Git 代码库,不允许拉取显式版本,这给出了包含head_rev
的符号引用,应从head_repository
拉取。head_tag
附加到版本的标签(如果有)。
files_changed
推送添加或修改的所有文件的列表。
owner
指示推送人的电子邮件地址。请注意,此值可能是伪造的,并且**绝不能**依赖于身份验证。
message
提交消息中的 try 语法(如果有)。
pushlog_id
hg.mozilla.org
推送日志中的 IDpushdate
触发此决策任务的代码库推送的时间戳。表示为自 UNIX 纪元以来的整数秒。
hg_branch
版本所在的 Mercurial 分支。
build_date
构建日期的时间戳。默认为
pushdate
,并回退到 taskgraph 调用的当前时间。表示为自 UNIX 纪元以来的整数秒。moz_build_date
build_date
的格式化时间戳。表示为具有以下格式的字符串:%Y%m%d%H%M%Srepository_type
代码库类型,可以是
hg
或git
。tasks_for
用于生成决策任务的
tasks_for
值。
树信息¶
project
树、分支或代码库的其他名称。这是非限定名称,例如
mozilla-central
或cedar
。level
与此树关联的 SCM 级别。这决定了生成的任务中使用的资源名称,如果错误,这些任务将失败。
Try 配置¶
try_mode
Try 推送运行的模式。这可以是以下之一
"try_task_config"
- 用于配置任务图。"try_option_syntax"
- 使用旧版 try 语法推送到 try 时使用。"try_auto"
- 用于使 try 推送的行为更像在autoland
上的推送。"try_select"
- 由mach try
用于在本地构建任务列表。None
- 不是 try 推送或mach try release
。
try_options
作为 try 语法给出的参数(作为字典),或者如果
try_mode
不是try_option_syntax
则为None
。try_task_config
try_task_config.json
文件的内容,或者如果try_mode
不是try_task_config
则为{}
。
测试配置¶
test_manifest_loader
要使用的测试清单加载器,如
taskgraph.util.chunking.manifest_loaders
中所定义。
目标集¶
“目标集”是必须包含在任务图中的任务标签集。任务图生成过程将递归地包含目标集中任务所需的任何任务。在决策任务中,可以使用多种方法以编程方式指定此集(例如,解析 try 语法或读取特定于项目的配置文件)。
enable_always_target
可以是布尔值或种类列表。
当
True
时,任何具有always_target
属性的任务都将包含在target_task_graph
中,而不管它们是否被target_tasks_method
过滤掉。因为它们不是target_set
的一部分,所以当optimize_target_tasks
参数为False
时,它们仍然有资格进行优化。当指定为种类列表时,只有具有匹配种类的任务才有资格添加到图中。
filters
要应用的过滤器函数列表(来自
taskcluster/gecko_taskgraph/filter_tasks.py
)。这通常在内部定义,因为过滤器通常是全局的。target_tasks_method
用于确定目标任务集的方法。这是
taskcluster/gecko_taskgraph/target_tasks.py
中某个函数的后缀。release_history
按平台和语言环境划分的最近版本的版本历史记录,用于在为夜间版本生成部分更新时使用。可以使用
mach release-history
生成合适的內容,默认情况下它会打印到控制台。
优化¶
optimize_strategies
形式为
<module>:<object>
的 Python 路径,其中包含要使用的优化策略字典,覆盖默认值。optimize_target_tasks
如果为真,则目标任务有资格进行优化。
do_not_optimize
指定不应从图中优化的任务。这是一个标签列表。与其中一个标签匹配的图中的任何任务都不会从图中优化掉。
existing_tasks
指定要从图中优化的任务。这是一个标签到 taskId 的字典。与其中一个标签匹配的图中的任何任务都将使用先前运行的 taskId,而不是提交新任务。
发布升级¶
build_number
指定发布升级构建编号。
version
为发布任务指定版本。
app_version
为发布任务指定应用程序版本。对于发布版本,这通常比
version
不那么具体的版本号。next_version
为版本升级任务指定下一个版本。
release_type
正在升级的发布类型。可以是“nightly”、“beta”、“esr115”、“esr128”、“release-rc”或“release”。
release_eta
计划发布上线的时间和日期。此值传递给 Balrog。
release_enable_partner_repack
控制为合作伙伴重新打包原生 Firefox 版本的布尔值。
release_enable_partner_attribution
控制为合作伙伴的原生 Firefox 版本添加归属信息的布尔值。
release_enable_emefree
控制将原生 Firefox 版本重新打包为无 EME 版本的布尔值。
release_partners
如果只是配置的一部分,则需要重新打包或添加归属信息的合作伙伴列表。空值默认为全部。
release_partner_config
合作伙伴重新打包和归属以及无 EME 重新打包的配置。
release_partner_build_number
合作伙伴重新打包的版本号。有时每个发行版本号都有多个合作伙伴版本号;此参数允许我们独立地递增它们。默认为 1。
release_product
正在发布的产品。
required_signoffs
此发布推广风格所需的批准列表。如果指定,并且相应的 signoff_urls url 未指定,则需要这些批准的任务将不会被安排。
signoff_urls
批准键到 url 值的字典。这些是将相应的
required_signoffs
标记为已批准的 url。
代码库合并日¶
merge_config
合并配置描述了代码库合并行为,使用别名来涵盖所需的文件替换和版本增量集,以及源和目标代码库 URI 的覆盖。
source_repo
源代码库的克隆/推送 URI,例如 https://hg.mozilla.org/mozilla-central
target_repo
目标代码库的克隆/推送 URI,例如 https://hg.mozilla.org/releases/mozilla-beta
source_branch
源分支的 firefoxtree 别名,例如‘central’、‘beta’
target_branch
目标分支的 firefoxtree 别名,例如‘beta’、‘release’
force-dry-run
不要将任何结果推送到目标代码库。
代码审查¶
phabricator_diff
代码审查流程需要知道启动分析的 Phabricator Differential diff。此参数必须以 PHID-DIFF- 开头
本地配置¶
target-kinds
仅生成给定的种类及其种类依赖项。这用于本地检查图,在运行时不支持。