Azure Pipelines - Sprint 253 Update

2025-03-20

Features

Hosted image updates
Workload identity federation uses Entra issuer
Gradle@4 task
Identity of user who requested a stage to run

Hosted image updates

We’re rolling out updates to keep Azure Pipelines’ hosted agents secure and current. These updates include adding support for Ubuntu-24.04, Windows 2025 images, and macOS-15 Sequoia, while deprecating older images like Ubuntu-20.04 and Windows Server 2019.

For more details, please visit our blog post.

macOS-15 Sequoia is generally available

The macOS-15 image will be available on Azure Pipelines hosted agents starting April 1. To use this image, update your YAML file to include vmImage:'macos-15':

- job: macOS15
  pool:
    vmImage: 'macOS-15'
  steps:
  - bash: |
      echo Hello from macOS Sequoia
      sw_vers

For macOS-15 installed software, see image configuration.

The macOS-14 image will still be used when specifying macOS-latest. We'll update macOS-latest to use macOS-15 in April.

Windows-2025 image is available in preview

The windows-2025 image is now available in preview for Azure Pipelines hosted agents. To use this image, update your YAML file to include vmImage:'windows-2025':

- job: win2025
  pool:
    vmImage: 'windows-2025'
  steps:
  - pwsh: |
      Write-Host "(Get-ComputerInfo).WindowsProductName"
      Get-ComputerInfo | Select-Object WindowsProductName
      Write-Host "`$PSVersionTable.OS"
      $PSVersionTable.OS

For Window Server 2025 installed software, see image configuration.

The ubuntu-latest pipeline image will start using ubuntu-24.04

In the coming weeks, pipeline jobs specifying ubuntu-latest will start using ubuntu-24.04 instead of ubuntu-22.04.

For guidance on tasks that use tools that are no longer on the ubuntu-24.04 image, see our blog post. To keep using Ubuntu 22.04, use the ubuntu-22.04 image label:

- job: ubuntu2404
  pool:
    vmImage: 'ubuntu-24.04'
  steps:
  - bash: |
      echo Hello from Ubuntu 24.04
      lsb_release -d
  - pwsh: |
      Write-Host "`$PSVersionTable.OS"
      $PSVersionTable.OS

The ubuntu-20.04 pipeline image is deprecated and will be retired April 1

We're deprecating support for the Ubuntu 20.04 image in Azure Pipelines because it will reach its end of support soon. Find the deprecation plan with brownout schedule in our blog post.

Workload identity federation uses Entra issuer

Just over a year ago, we made Workload identity federation generally available. Workload identity federation allows you to configure a service connection without a secret. The identity (App registration, Managed Identity) underpinning the service connection can only be used for the intended purpose: the service connection configured in the identity's federated credential.

We're now changing the format of the federated credential for new Azure and Docker service connections. Existing service connections will work as before.

	Azure DevOps issuer	Entra issuer (new service connections)
Issuer	`https://vstoken.dev.azure.com/<organization id>`	`https://login.microsoftonline.com/<Entra tenant id>/v2.0`
Subject	`sc://<organization name>/<project name>/<service connection name>`	`<entra prefix>/sc/<organization id>/<service connection id>`

There's no change in configuration and the way tokens are obtained stays the same. Pipeline tasks don't need to be updated and work as before.

The steps to create a service connection aren't changing and in most cases, the new issuer isn't visible. When configuring an Azure service connection manually, you'll see the new federated credentials displayed:

Copy these values as before when creating a federated credential for an App registration or Managed Identity.

Automation

When creating a service connection in automation with the REST API, use the federated credential returned by the API:

authorization.parameters.workloadIdentityFederationIssuer
authorization.parameters.workloadIdentityFederationSubject

Likewise, when creating a service connection with the Terraform azuredevops provider, the azuredevops_serviceendpoint_azurerm resource returns workload_identity_federation_issuer and workload_identity_federation_subject attributes.

More information

Gradle@4 task

A new Gradle@4 task has been created with support for Gradle 8.0. The built-in code coverage option is removed from the Gradle task starting with Gradle@4. To use code coverage with Gradle in your pipeline:

Specify code coverage plugins in your build.gradle file. For more information, see Gradle code analysis options.
Use the PublishCodeCoverageResults@2 task in your pipeline after the Gradle@4 task.

Configuration of the SonarQube analysis was moved to the SonarQube or SonarCloud extensions in the task Prepare Analysis Configuration.

Identity of user who requested a stage to run

To improve security of your YAML pipelines, you may wish to know who requested a stage to run. To address this need, were adding two new predefined variables, Build.StageRequestedBy and Build.StageRequestedById. These variables are similar to the Build.RequestedFor and Build.RequestedForId variables, but for a stage, not a run.

When a user explicitly triggers a user, for example, in case of a manually triggered stage or rerunning a stage, their identity is used to fill in the two variables.

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.

Share via