Azure Pipelines - Sprint 195 更新
功能
任务的自动重试
如果管道中存在间歇性失败的不规则任务,可能需要重新运行管道才能成功。 在大多数情况下,解决不规则任务或脚本的最佳方法是修复任务或脚本本身。 例如,如果测试任务在管道中由于不规则测试而失败,则修复不规则的测试并使其更可靠始终是一个好主意。 同样,如果脚本不时失败,最好修复脚本,例如在脚本中引入重试。
但是,在某些情况下,可能需要重试任务。 一个常见的用例是下载包 (,例如 NuGet、npm 等) 。 我们经常观察到,这些任务容易受到网络故障和包托管服务器上的暂时性故障的影响。 我们收到了你的反馈,建议自动重试此类失败的任务,而无需再次重启整个管道。
根据你的反馈,我们添加了一项功能,用于在失败时自动重试管道中的任务。 如果使用 YAML 管道,则可以按如下所示设置此输入:
- task: <name of task>
retryCountOnTaskFailure: <max number of retries>
...
使用经典生成或发布管道时,可以在任务的控制选项下设置此属性。
下面是使用重试时需要注意的一些事项:
- 将立即重试失败的任务。
- 对于任务的幂等性,不做任何假设。 如果任务具有副作用(例如,如果任务部分创建了外部资源),则可能会在第二次运行时失败。
- 没有为任务提供关于重试次数的信息。
- 系统会向任务日志添加一条警告,指示它在重试之前已失败。
- 所有重试任务尝试都作为同一任务节点的一部分显示在 UI 中。
注意
需要代理版本 2.194.0 或更高版本。 不支持无代理任务。
在修饰器中使用来自另一个任务的输入
我们最近添加了一项 功能 ,用于在管道中的另一个目标任务之前自动将任务注入管道。 我们现在通过允许使用目标任务的输入参数自定义注入任务来增强该功能。 编写修饰器以执行此操作的语法如下所示:
{
"contributions": [
{
"id": <my-required-task>,
"type": "ms.azure-pipelines.pipeline-decorator",
"targets": [
"ms.azure-pipelines-agent-job.pre-task-tasks",
"ms.azure-pipelines-agent-job.post-task-tasks"
],
"properties": {
"template": "my-decorator.yml",
"targettask": <target-task-id>,
"targettaskinputs": ["<name of input>"]
}
}
],
...
}
仅当使用 pre-task-tasks
或 post-task-tasks
作为注入目标并在贡献的属性部分中指定 targettask
时,此功能才有效。 然后,可以添加名为 targettaskinputs
的附加属性,并指定目标任务接受的输入参数名称列表。 这些输入现在可供注入的任务使用。
此类方案可以实现的常见用例如下所示。 假设要注入一个任务,该任务将自动记录生成发布的项目的名称。 项目的名称是任务的输入 PublishBuildArtifacts
。 注入的任务现在可以获取相同的输入参数并将其用于日志记录。
服务连接使用历史记录的改进
当管道使用 服务连接时,该使用情况将记录在连接的历史记录中。 服务连接的管理员可以通过导航到项目设置并选择适当的服务连接来查看使用历史记录。 此更新修复了服务连接的使用历史记录存在一些问题。 修复方法包括:
- 在 部署作业 (而不是常规作业) 中使用服务连接时,未记录该使用情况。
- 如果在管道的多个阶段中使用了多个服务连接,则即使跳过了某些阶段,所有服务连接也会在其使用历史记录中显示一条记录。
经典管道的默认代理规范现在是 Windows-2019
在上一个发行说明中,我们 宣布了 托管映像的 vs2017-win2016
弃用计划。 为此,我们现在在经典管道中创建新管道时将默认代理规范更改为 windows-2019
。
后续步骤
注意
这些功能将在未来两到三周内推出。
前往 Azure DevOps 并查看。
如何提供反馈
我们很想听听你对这些功能的看法。 使用帮助菜单报告问题或提供建议。
你还可以在 Stack Overflow 上获得社区的建议和问题的答案。
反馈
https://aka.ms/ContentUserFeedback。
即将发布:在整个 2024 年,我们将逐步淘汰作为内容反馈机制的“GitHub 问题”,并将其取代为新的反馈系统。 有关详细信息,请参阅:提交和查看相关反馈