NuGet、npm 和其他项目任务支持代理 - Sprint 147 更新
在 Azure DevOps 的 Sprint 147 更新 中，我们更新了与项目相关的各种管道任务以支持代理。 通过此更新，代理现在可在 npm、NuGet、.NET Core 和通用包任务中使用。
有关详细信息，请查看下面的 功能 列表。
功能
常规：
Azure Boards：
Azure Repos：
Azure Pipelines：
- 还原已删除的发布管道
- 新管道的 YAML 文件由你的标识提交，而不是由机器人提交
- 从任何分支或路径中的现有 YAML 文件创建管道
- 使用 GitHub 拉取请求注释运行管道
- 将拉取请求验证版本限制为授权团队成员
- 发布具有长文件路径的生成项目
- “管道测试”选项卡中的新扩展贡献点
Azure Artifacts：
报表：
Wiki：
常规
所有用户现在都使用“新建导航”
在此冲刺中，所有用户都已移动到“新建导航”。 我们删除了允许用户返回到以前的导航模型的预览功能切换。 若要详细了解如何在 Web 门户中导航，请参阅 Azure DevOps 中的 Web 门户导航。
Azure Boards
在#ID提及中显示工作项状态
为了增强工作项提及体验，当你使用 #ID 链接工作项时，我们添加了更多信息。 现在，除了 ID、标题和工作项类型外，你还将在讨论部分看到所链接的工作项的状态。
此体验还可以在 Wiki 页面（如此处所述）以及拉取请求评论中使用。 有关更多详细信息，请参阅 此处有关使用 #ID 链接到工作项的文档。
Azure Repos
仅查看拉取请求中的左侧或右侧文件
目前，在拉取请求中查看文件更改时，可以使用并排差异模式或内联差异模式。 我们收到了反馈，你们中的许多人只想查看原始文件或更改的文件，而不进行比较。 因此，我们添加了一个新选项，用于单独查看左侧文件或右侧文件。
Azure Pipelines
还原已删除的发布管道
删除未使用的发布管道有助于保持发布管道列表的干净，但有时会错误地删除某些内容。 通过此更新，现在可以还原过去 30 天内删除的发布管道。 我们在“发布”页的左侧面板中添加了一个新选项卡，该选项卡将显示已删除的发布管道的列表。 在此视图中，可以通过从列表中选择管道并单击“ 还原 ”按钮来还原已删除的发布管道。
新管道的 YAML 文件由你的标识提交，而不是由机器人提交
创建管道时，Azure Pipelines 会选择性地将 YAML 文件提交到存储库，然后为管道创建拉取请求。 以前，如果存储库位于 GitHub 上，并且你安装了 Azure Pipelines GitHub Apps，则提交和拉取请求似乎是由GitHub Apps创建的：“Azure Pipelines [bot]”。 通过此更新，我们将你的 GitHub 标识显示为管道的创建者，而不是GitHub Apps。
从任何分支或路径中的现有 YAML 文件创建管道
目前，创建新管道时，Azure Pipelines 将检测并自动使用名为 azure-pipelines.yml 或 .azure-pipelines.yml 的现有 YAML 文件，该文件位于默认分支存储库的根目录中。 通过此更新，可以选择具有不同名称或路径的现有 Azure Pipelines YAML 文件，或者选择非默认分支。
若要选择现有文件，请在 “新建生成管道 ”向导配置页中选择“ 现有 Azure Pipelines YAML 文件”。 然后，选择分支并浏览以选择 YAML 文件路径。
使用 GitHub 拉取请求注释运行管道
通过此更新，可以运行管道或测试套件，从该 PR 的注释部分验证 GitHub 拉取请求。 任何所有者或协作者都可以使用 /AzurePipelines run 或 /AzurePipelines run <pipeline_name> 对拉取请求进行注释以触发生成。
还可以将 /AzurePipelines 名字对象缩写为 /azp。 有关此功能的更多详细信息，请在注释中键入 /azp help 。
将拉取请求验证版本限制为授权团队成员
通过实施拉取请求验证生成来保护分支的质量是一种很好的做法。 到目前为止，这些验证生成是由任何 GitHub 拉取请求自动触发的，这可能会有风险，因为无需你审查即可启动生成。
通过此更新，可以要求团队授权拉取请求验证版本。 为此，请在管道设置中选择“触发器”选项卡。 然后，在“拉取请求验证”下，为协作者的拉取请求注释启用“仅触发生成”并保存管道。
现在，拉取请求验证生成不会自动触发。 任何存储库所有者或参与者都可以通过使用 或 /AzurePipelines run <pipeline_name>注释拉取请求/AzurePipelines run来触发验证生成。
发布具有长文件路径的生成项目
到目前为止，存在一个限制，导致无法上传路径长度超过 233 个字符的生成项目。 这可能会阻止上传文件路径长于限制的 Linux 和 macOS 版本的代码覆盖率结果。 通过此更新，我们扩展了限制以支持长路径。
“管道测试”选项卡中的新扩展贡献点
在此冲刺中，我们继续通过在管道的“测试结果”选项卡中添加两个新的贡献点，使扩展框架更加强大。 这将使 市场扩展 能够提供更定制的报告体验，并添加进一步的交互性。
两个贡献点是：
工具栏中的“自定义操作”按钮
有时，你可能想要执行更新 API 数据或使用测试结果中的元数据运行自定义工具等操作。 使用此贡献点，可以创建扩展，这些扩展使用所选测试结果的直接上下文将自定义操作添加到 *自定义操作- 按钮。
详细信息窗格中的“自定义详细信息”选项卡
你可能有各种各样的测试报表使用工作流，并且可能想要针对失败的测试查看不同的数据点，以便进行调试和分析。 使用此贡献点，团队可以将新选项卡添加到详细信息窗格中，当你选择数据网格中的任何测试结果行时，该选项卡将会出现该选项卡。 此新选项卡可以显示包含静态内容或使用内部或外部 API 提取的动态数据的视图。
Azure Artifacts
对项目相关任务的代理支持
到目前为止，许多与项目相关的生成任务都没有为 Azure Pipelines 的代理基础结构提供完全支持，这导致了使用本地代理中任务的挑战。 在此更新中，我们已向以下任务添加了对代理的支持：
- npm
- NuGet - 仅还原和推送命令
- .NET Core CLI - 仅还原和 NuGet 推送命令
- 通用包
- npm Authenticate、 Pip Authenticate、 Twine Upload Authenticate
注意
这些任务不会为基础工具配置代理， (npm、pip、twine) 。 它们在获取身份验证令牌期间支持代理，但仍需要配置任何后续任务/脚本/工具以使用代理。
- .NET Core 工具安装程序、NuGet 工具安装程序Node.js工具安装程序
委托可以管理源的人员
在 Azure Artifacts 中， 项目集合管理员 (PCA) 始终能够管理 Azure DevOps 组织中的所有源。 通过此更新，PCA 还可以向其他用户和组提供此功能，从而委派管理任何源的功能。
报表
高级) 小组件 (测试结果趋势
高级 ) 小组件 (测试结果趋势 现在适用于在其 Azure DevOps 组织中安装了 Analytics 扩展 的用户。 它提供对多个生成和发布的测试数据的准实时可见性。 “ 测试结果趋势 (高级) 小组件 显示管道或跨管道的测试结果趋势。 可以使用它来跟踪每日测试计数、通过率和测试持续时间。 随时间推移跟踪测试质量并改进测试附属品是维护正常 DevOps 管道的关键。
“ 测试结果趋势 (高级) ”小组件 可帮助你发现测试结果中的离群值，并回答如下问题：测试的运行时间是否比平时长？ 哪个测试文件或管道会影响我的总体通过率？ 我长时间运行的测试是什么？
为了帮助你回答这些问题，小组件提供了以下功能：
- 显示通过率的趋势，以及测试结果或测试持续时间的计数
- 基于多个生成管道或发布管道显示测试结果
- 使用组合图表选项显示同一趋势的两个指标
- 按测试结果筛选一段时间内的测试计数
- 按分支或测试筛选所有测试结果
- 按测试属性（例如优先级或环境）堆叠指标
- 在测试文件、所有者或管道上对数据进行分组
小组件具有高度可配置性，允许将其用于各种方案。
Wiki
Wiki 网页的永久链接
到目前为止，如果链接页面已重命名或移动，共享 Wiki 页面链接会中断。 通过此更新，我们通过向 URL 添加页面 ID 来引入永久链接。 这可确保随着 Wiki 随时间推移的变化，您共享的链接保持不变。
此功能的优先级基于建议票证。
在 Wiki 页面中显示工作项状态
在此更新中，我们通过将工作项的状态及其 ID 和标题添加到页面，增强了 Wiki 页面中的工作项提及。
拉取请求注释和 Boards 讨论中的工作项引用也会显示状态。
此功能已根据建议设置优先级。
后续步骤
注意
这些功能将在未来两到三周内推出。
前往 Azure DevOps 并查看。
如何提供反馈
我们很想听听你对这些功能的看法。 使用反馈菜单报告问题或提供建议。
你还可以在 Stack Overflow 上获得社区的建议和问题的答案。
此致
亚历克斯·穆兰斯
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈