Edit

Share via

Support for wild cards and conditional expressions in YAML pipeline files

  • Article

In this sprint, we included support for wild cards and conditional expressions to YAML pipeline files. In addition, we've made multiple updates to the Azure Pipelines hosted images.

Check out the following feature descriptions for details.

Azure Pipelines

Azure Repos

Azure Pipelines

New YAML conditional expressions

Writing conditional expressions in YAML files just got easier with the use of ${{ else }} and ${{ elseif }} expressions. Below are examples of how to use these expressions in YAML pipelines files.

steps:
- script: tool
  env:
    ${{ 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

Support for wild cards in path filters

Wild cards can be used when specifying inclusion and exclusion branches for CI or PR triggers in a pipeline YAML file. However, they can't be used when specifying path filters. For instance, you can't include all paths that match src/app/**/myapp*. This has been pointed out as an inconvenience by several customers. This update fills this gap. Now, you can use wild card characters (**, *, or ?) when specifying path filters.

Support for multiple statuses in Bitbucket

Azure Pipelines integrates with Bitbucket repositories and supports CI and PR triggers. You can set up multiple pipelines from a single Bitbucket repository. However, when these pipelines were complete, you could only see one status in Bitbucket. We heard feedback from the Developer Community asking to view the status of each pipeline separately in Bitbucket. With this update, we updated our API calls to Bitbucket and pass additional information about the name of the pipeline.

Build status

Allow contributors to skip seeking PR comments prior to build validation

When using Azure Pipelines with GitHub repositories, we recommend that you don't automatically run a PR validation pipeline for contributions received from a forked repository. The best practice here's to first have one of the collaborators of the repository review the change and then add a comment to the PR to trigger the pipeline. You can configure these settings by selecting the Triggers menu (for YAML pipelines) or the Triggers tab (for classic build pipelines) in the pipeline web editor. Instead of requiring every PR from a fork to be first reviewed by a team member, you can also enforce this policy only on contributions that originate from non-team members.

With this update, we're allowing you to skip seeking a PR comment from contributions received by any contributor. As a non-team member, when you create a fork and create a PR to the upstream, you aren't considered a contributor to the upstream repository until your PR is merged. Once your PR is merged, you'll be considered a contributor. By selecting the new option shown below, when a non-team member submits a PR from a fork for the first time, someone on your team would have to review the PR and add a comment to trigger the pipeline. But, once the PR is merged, any further contributions made by that non-team member will directly trigger the pipeline without waiting for a PR comment.

Require a team member's comment before building a pull request

Windows Server 2022 with Visual Studio 2022 is now available on Microsoft-hosted agents (preview)

Windows Server 2022 and Visual Studio Enterprise 2022 Preview are now available in preview on Microsoft-hosted agents. You can use it by referencing windows-2022 as image in your pipeline.

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'

When you reference windows-latest pool in your YAML pipelines, it will still mean windows-2019 and not windows-2022, while the latter is in preview.

The Windows Server 2022 pipeline image has different tools and tool versions when compared to Windows Server 2019. You can see the details in the software announcement issue and in the documentation virtual-environments repository.

General availability of macOS 11 on Microsoft-hosted agents

macOS 11 is now generally available on Microsoft-hosted agents. You can use it by referencing macos-11 as image in your pipeline.

pool:
  vmImage: macos-11

Removal of Ubuntu 16.04 image on Microsoft-hosted agents

As announced earlier, we'll be removing Ubuntu 16.04 image from Microsoft-hosted agents on September 20, 2021. Traditional 5-years support of Ubuntu 16.04 by Canonical ended in April, 2021. You'll need to migrate ubuntu-16.04 pipelines to ubuntu-18.04 or ubuntu-latest which will run on Ubuntu 20.04 LTS.

Builds that use Ubuntu-16.04 already have a warning being logged in them. To make sure everyone is aware of this change, we scheduled 2 short "brownouts". Ubuntu 16.04 builds will fail during the brownout period. Therefore, it's recommended to migrate your workflows prior to the September 6, 2021.

The brownouts are scheduled for the following dates and times (Note that these have been extended by an hour from the earlier announced times): September 6, 2021 4:00pm UTC – 10:00pm UTC September 14, 2021 4:00pm UTC – 10:00pm UTC

Azure Repos

New TFVC pages are generally available

We have been updating various pages in Azure DevOps to use a new web platform with the goal of making the experience more consistent and more accessible across the various services. TFVC pages have been updated to use the new web platform, and those changes have been in preview for several months now. With this update, we are making the new TFVC pages generally available. With this update, you will no longer see a preview feature called "New TFVC pages" in their user settings.

Configure branch creators to not get "Manage permissions" on their branches

When you create a new branch, you get "Manage permissions" on that branch. This permission lets you change the permissions of other users or admit additional users to contribute to that branch. For instance, a branch creator may use this permission to allow another external user to make changes to the code. Or, they may allow a pipeline (build service identity) to change the code in that branch. In certain organizations with higher compliance requirements, users should not be able to make such changes.

With this update, you can configure any and all repositories in your team project and restrict branch creators from getting the "Manage permissions" permission. To do this, navigate to the project settings, select Repositories, and then Settings for all repositories or a specific repository.

All repositories settings

This setting is on by default to mimic the existing behavior. But, you can turn it off if you wish to make use of this new security feature.

Prevent fork users from voting on their upstream PRs

With Azure Repos, users with "read" permission on a repository can fork the repo and make changes in their fork. To submit a pull request with their changes to the upstream, users need "contribute to pull requests" permission on the upstream. However, this permission also governs who can vote on pull requests in the upstream repository. As a result, you can end up in situations where a user, who is not a contributor to the repository, can submit a pull request and cause it to be merged depending on how you set up the branch policies.

In organizations that promote an inner-source model, fork-and-contribute is a common pattern. To secure and promote this pattern further, we are changing the permission to vote on a pull request from "contribute to pull requests" to "contribute". However, this change is not being made by default in all organizations. You have to opt-in and select a new policy on your repository, called "Strict Vote Mode" to switch this permission. We recommend that you do so if you rely on forks in Azure Repos.

Repository settings

Next steps

Note

These features will roll out over the next two to three weeks.

Head over to Azure DevOps and take a look.

Go to Azure DevOps

How to provide feedback

We would love to hear what you think about these features. Use the help menu to report a problem or provide a suggestion.

Make a suggestion

You can also get advice and your questions answered by the community on Stack Overflow.

Thanks,

Aaron Hallberg