尝试

“尝试”是一种在审查之前安全地“尝试”提议更改的方法，而无需正式落地。此功能已以各种形式存在了很长时间，有时可能会显现出其年代感。

与可以将更改落地到集成和发布分支的开发人员相比，“推送到尝试”的访问权限通常可供更多开发人员使用。具体来说，对于任何拥有SCM 级别 1 的人，都允许尝试推送，而集成分支则处于 SCM 级别 3。

在尝试中安排任务

有三种方法可以在尝试中安排任务：旧的尝试选项语法、尝试任务配置和空尝试。

尝试选项语法

第一种，较旧的方法是称为try syntax的命令行字符串，它通过提交消息传递到决策任务。生成的提交随后会被推送到https://hg.mozilla.org/try 存储库。尝试语法的示例可能如下所示

try: -b o -p linux64 -u mochitest-1 -t none

这将由taskgraph.try_option_syntax:TryOptionSyntax解析，并返回匹配的任务标签列表。有关更多信息，请参阅TryServer 维基页面。

尝试任务配置

第二种，更现代的方法精确指定要运行的任务。该任务列表通常使用某些本地工具在本地生成，并附加到推送到尝试存储库的提交中。这提供了对确切运行内容的更精细控制，并支持构建适合各种情况的工具生态系统。

实施

此方法使用名为try_task_config.json的签入文件，该文件位于源目录的根目录。此文件中的 JSON 对象包含一个tasks键，用于提供要运行的任务的标签。例如，try_task_config.json文件可能如下所示

{
  "version": 1,
  "tasks": [
    "test-windows10-64/opt-web-platform-tests-12",
    "test-windows7-32/opt-reftest-1",
    "test-windows7-32/opt-reftest-2",
    "test-windows7-32/opt-reftest-3",
    "build-linux64/debug",
    "source-test-mozlint-eslint"
  ]
}

非常简单，这将运行作为参数传入的任何任务标签及其依赖项。虽然可以手动提交此文件并推送到尝试，但它主要旨在作为各种尝试服务器选择器的生成目标。例如

$ ./mach try fuzzy

可以通过运行以下命令获取所有可能的任务标签列表：

$ ./mach taskgraph tasks

可以通过以下命令获取与树相关的任务标签列表（默认为 mozilla-central）：

$ ./mach taskgraph target

修改尝试推送中的任务

可以通过在try_task_config.json中定义其他配置来更改任务的定义。例如，要在所有任务中设置环境变量，可以添加

{
  "version": 1,
  "tasks": [...],
  "env": {
    "FOO": "bar"
  }
}

允许的配置在taskgraph.decision.try_task_config_schema中定义。这些值将可用于所有转换，因此每个配置的应用方式在不同的上下文中会有很大差异。某些（例如env）将影响图中的所有任务。其他一些可能只影响某些类型的任务。use-artifact-builds配置仅适用于构建任务，例如。

空尝试

如果没有尝试语法或try_task_config.json，则try_mode参数为 None，并且不会选择任何任务运行。生成的推送将仅包含一个决策任务，但该任务具有“添加作业”操作，可用于将所需的作业添加到尝试推送中。

复杂配置

如果您需要更多地控制构建配置（例如暂存发布），您可以直接指定参数以从try_task_config.json覆盖，如下所示

{
    "version": 2,
    "parameters": {
        "optimize_target_tasks": true,
        "release_type": "beta",
        "target_tasks_method": "staging_release_builds"
    }
}

此格式可以表达版本 1 格式的超集，因为版本 1 配置等效于以下版本 2 配置。

{
    "version": 2,
    "parameters": {
        "try_task_config": {...},
        "try_mode": "try_task_config",
    }
}