在此冲刺中,我们包括对 YAML 管道文件的通配符和条件表达式的支持。 此外,我们还对 Azure Pipelines 托管映像进行了多次更新。

有关详细信息,请查看以下功能说明。

Azure Pipelines

  • 新的 YAML 条件表达式
  • 支持路径筛选器中的通配符
  • 支持 Bitbucket 中的多个状态
  • 允许参与者在生成验证之前跳过寻求 PR 注释
  • Visual Studio 2022 的 Windows Server 2022 现已在 Microsoft 托管的代理上提供, (预览版)
  • Microsoft 托管代理上的 macOS 11 Big Sur 正式发布
  • 删除 Microsoft 托管代理上的 Ubuntu 16.04 映像
  • Azure Repos

  • 新的 TFVC 页面已正式发布
  • 将分支创建者配置为不在其分支上获取“管理权限”
  • 阻止分叉用户在其上游 PR 上投票
  • Azure Pipelines

    新的 YAML 条件表达式

    在 YAML 文件中编写条件表达式只是使用和 ${{ elseif }} 表达式更容易 ${{ else }} 。 下面是如何在 YAML 管道文件中使用这些表达式的示例。

    steps:
    - script: tool
        ${{ if parameters.debug }}:
          TOOL_DEBUG: true
          TOOL_DEBUG_DIR: _dbg
        ${{ else }}:
          TOOL_DEBUG: false
          TOOL_DEBUG_DIR: _dbg
    
    variables:
      ${{ if eq(parameters.os, 'win') }}:
        testsFolder: windows
      ${{ elseif eq(parameters.os, 'linux') }}:
        testsFolder: linux
      ${{ else }}:
        testsFolder: mac
    

    支持路径筛选器中的通配符

    指定管道 YAML 文件中 CI 或 PR 触发器的包含和排除分支时,可以使用通配符。 但是,指定路径筛选器时不能使用它们。 例如,不能包含匹配 src/app/**/myapp*的所有路径。 这一点被几个 客户指出为不便。 此更新填补了此空白。 现在,可以在指定路径筛选器时使用通配符 (***?) 。

    支持 Bitbucket 中的多个状态

    Azure Pipelines 与 Bitbucket 存储库集成,并支持 CI 和 PR 触发器。 可以从单个 Bitbucket 存储库设置多个管道。 但是,当这些管道完成时,只能在 Bitbucket 中看到一个状态。 我们听取了来自开发者社区的反馈,要求在 Bitbucket 中单独查看每个管道的状态。 通过此更新,我们更新了对 Bitbucket 的 API 调用,并传递有关管道名称的其他信息。

    允许参与者在生成验证之前跳过寻求 PR 注释

    将 Azure Pipelines 与 GitHub 存储库配合使用时, 建议 不要自动运行 PR 验证管道,以获取从分叉存储库接收的贡献。 最佳做法是先让存储库的其中一个协作者查看更改,然后将 注释 添加到 PR 以触发管道。 可以通过选择 YAML 管道) 的触发器菜单 (或管道 Web 编辑器中经典生成管道) 的触发器选项卡 (来配置这些设置。 除了要求团队成员首先审查分叉中的每个 PR 外,还可以仅对源自非团队成员的贡献强制实施此策略。

    通过此更新,我们可以跳过从任何参与者收到的贡献中查找 PR 注释。 作为非团队成员,在创建分支并创建上游 PR 时,在合并 PR 之前,不会被视为上游存储库的参与者。 合并 PR 后,你将被视为参与者。 通过选择下面所示的新选项,当非团队成员首次从分叉提交 PR 时,团队中的某人必须查看 PR 并添加注释以触发管道。 但是,合并 PR 后,该非团队成员做出的任何进一步贡献都会直接触发管道,而无需等待 PR 注释。

    Visual Studio 2022 的 Windows Server 2022 现已在 Microsoft 托管的代理上提供, (预览版)

    Windows Server 2022 和 Visual Studio Enterprise 2022 预览版现已在 Microsoft 托管代理上以预览版提供。 可以通过在管道中引用 windows-2022 为映像来使用它。

    pool:
      vmImage: 'windows-2022'
    steps:
    - task: NuGetToolInstaller@1
    - task: NuGetCommand@2
      inputs:
        restoreSolution: '**/*.sln'
    - task: VSBuild@1 # Visual Studio 2022 build
      inputs:
        solution: '**/*.sln'
        msbuildArgs: '/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:DesktopBuildPackageLocation="$(build.artifactStagingDirectory)\WebApp.zip" /p:DeployIisAppPath="Default Web Site"'
        platform: 'Any CPU'
        configuration: 'Release'
    

    在 YAML 管道中引用 windows-latest 池时,它仍表示 windows-2019 而不是 windows-2022,而后者处于预览状态。

    与 Windows Server 2019 相比,Windows Server 2022 管道映像具有不同的工具和工具版本。 可以在软件 公告问题和 文档 虚拟环境存储库中查看详细信息。

    Microsoft 托管代理上的 macOS 11 正式发布

    macOS 11 现已在 Microsoft 托管的代理上正式发布。 可以通过在管道中引用 macos-11 为映像来使用它。

    pool:
      vmImage: macos-11
    

    macOS 11 管道映像具有不同的工具和工具,若要了解有关此版本的详细信息,可 在此处查看完整文档。

    删除 Microsoft 托管代理上的 Ubuntu 16.04 映像

    前所述,我们将在 2021 年 9 月 20 日从 Microsoft 托管的代理中删除 Ubuntu 16.04 映像。 规范版对 Ubuntu 16.04 的传统 5 年支持于 2021 年 4 月结束。 需要将 ubuntu-16.04 管道迁移到 ubuntu-18.04 或 ubuntu-latest,该管道将在 Ubuntu 20.04 LTS 上运行。

    使用 Ubuntu-16.04 的生成中已经记录了警告。 为了确保每个人都知道这一变化,我们计划了 2 个简短的“棕色”。 Ubuntu 16.04 内部版本在棕色期间将失败。 因此,建议在 2021 年 9 月 6 日之前迁移工作流。

    淡化计划为以下日期和时间, (请注意,这些已延长一小时,从早些时候宣布的时间) :2021 年 9 月 6 日下午 4:00 UTC – 2021 年 9 月 14 日下午 10:00 UTC – 10:00 UTC - UTC 下午 10:00

    Azure Repos

    新的 TFVC 页面已正式发布

    我们一直在更新 Azure DevOps 中的各种页面,以使用新的 Web 平台,目的是使体验在各种服务中更加一致且更易于访问。 TFVC 页面已更新为使用新的 Web 平台,这些更改现已预览几个月。 通过此更新,我们将推出新的 TFVC 页面。 通过此更新,你将不再在其用户设置中看到名为“新建 TFVC 页面”的预览功能。

    将分支创建者配置为不在其分支上获取“管理权限”

    创建新分支时,会在该分支上获得“管理权限”。 此权限允许你更改其他用户的权限或允许其他用户参与该分支。 例如,分支创建者可以使用此权限允许另一个外部用户对代码进行更改。 或者,它们可能允许管道 (生成服务标识) 更改该分支中的代码。 在某些符合性要求较高的组织中,用户不应进行此类更改。

    通过此更新,你可以配置团队项目中的任何和所有存储库,并限制分支创建者获取“管理权限”权限。 为此,请导航到项目设置,选择“存储库”,然后为所有存储库或特定存储库设置。

    默认情况下,此设置处于打开状态以模拟现有行为。 但是,如果希望使用此新的安全功能,可以将其关闭。

    阻止分叉用户在其上游 PR 上投票

    使用Azure Repos,对存储库具有“读取”权限的用户可以分叉存储库并在其分支中进行更改。 若要将拉取请求与其对上游的更改一起提交,用户需要在上游“参与拉取请求”权限。 但是,此权限还控制谁可以在上游存储库中投票支持拉取请求。 因此,最终,在用户不是存储库参与者的情况下,可以提交拉取请求并导致合并,具体取决于如何设置分支策略。

    在提升内部源模型的组织中,分叉和贡献是一种常见模式。 为了进一步保护和提升此模式,我们将更改对拉取请求进行投票的权限,从“参与拉取请求”更改为“参与”。 但是,默认情况下不会在所有组织中进行此更改。 必须选择加入并在存储库上选择一个新策略,称为“严格投票模式”以切换此权限。 如果依赖于Azure Repos中的分叉,我们建议这样做。

    这些功能将在未来两到三周内推出。

    转到 Azure DevOps 并查看。

    转到 Azure DevOps

    如何提供反馈

    我们希望听到你对这些功能的看法。 使用帮助菜单报告问题或提供建议。

    还可以获取 Stack Overflow 上的社区解答的建议和问题。

    亚伦·霍尔伯格