Azure Pipelines - Mise à jour sprint 253

Fonctionnalités

• mises à jour d’images hébergées
• Fédération des Identités de charge de travail utilise l’émetteur Entra
• Tâche Gradle@4
• Identité de l’utilisateur qui a demandé qu’une étape s’exécute

Mises à jour d’images hébergées

Nous déployons des mises à jour pour sécuriser et mettre à jour les agents hébergés d’Azure Pipelines. Ces mises à jour incluent l’ajout de la prise en charge des images Ubuntu-24.04, Windows 2025, et de macOS-15 Sequoia, en supprimant progressivement les anciennes images comme Ubuntu-20.04 et Windows Server 2019.

Pour plus d’informations, consultez notre billet de blog .

macOS-15 Sequoia est généralement disponible

L’image macOS-15 sera disponible sur les agents hébergés par Azure Pipelines à compter du 1er avril. Pour utiliser cette image, mettez à jour votre fichier YAML pour inclure vmImage:'macos-15':

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

Pour les logiciels installés sur macOS-15, consultez configuration d’image.

L’image macOS-14 sera toujours utilisée lors de la spécification macOS-latest. Nous allons mettre à jour macOS-latest pour utiliser macOS-15 en avril.

L’image Windows-2025 est disponible en préversion

L’image windows-2025 est désormais disponible en préversion pour des agents hébergés Azure Pipelines. Pour utiliser cette image, mettez à jour votre fichier YAML pour inclure 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

Pour les logiciels installés par Windows Server 2025, consultez la configuration de l'image .

L’image de pipeline ubuntu-latest va commencer à utiliser ubuntu-24.04

Dans les semaines à venir, les travaux de pipeline spécifiant ubuntu-latest commenceront à utiliser ubuntu-24.04 au lieu de ubuntu-22.04.

Pour obtenir des conseils sur les tâches qui utilisent des outils qui ne sont plus sur l’image ubuntu-24.04, consultez notre billet de blog . Pour continuer à utiliser Ubuntu 22.04, utilisez l’étiquette d’image ubuntu-22.04 :

- 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

L’image de pipeline ubuntu-20.04 est déconseillée et sera mise hors service le 1er avril

Nous cessons de prendre en charge l’image Ubuntu 20.04 dans Azure Pipelines, car elle atteindra bientôt la fin de son support. Trouvez le plan d’obsolescence avec le calendrier de réduction dans notre billet de blog.

Fédération des Identités de charge de travail utilise l’émetteur Entra

Depuis un peu plus d’un an, la Fédération des identités de charge de travail est généralement disponible. La fédération des identités de charge de travail vous permet de configurer une connexion de service sans secret. L’identité (inscription d’application, identité managée) qui sous-tend la connexion de service ne peut être utilisée qu’à des fins prévues : la connexion de service configurée dans les informations d’identification fédérées de l’identité.

Nous modifions maintenant le format des informations d’identification fédérées pour les nouvelles connexions de service Azure et Docker. Les connexions de service existantes fonctionnent comme avant.

	Émetteur Azure DevOps	Émetteur Entra (nouvelles connexions de service)
Émetteur	https://vstoken.dev.azure.com/<organization id>	https://login.microsoftonline.com/<Entra tenant id>/v2.0
Sujet	sc://<organization name>/<project name>/<service connection name>	<entra prefix>/sc/<organization id>/<service connection id>

Il n’existe aucune modification de la configuration et la façon dont les jetons sont obtenus reste identique. Les tâches de pipeline n’ont pas besoin d’être mises à jour et de fonctionner comme avant.

Les étapes de création d’une connexion de service ne changent pas et, dans la plupart des cas, le nouvel émetteur n’est pas visible. Lors de la configuration d’une connexion de service Azure manuellement, vous verrez les nouvelles informations d’identification fédérées affichées :

Copiez ces valeurs comme avant lors de la création d’informations d’identification fédérées pour une inscription d’application ou une identité managée.

Automatisation

Lors de la création d’une connexion de service dans l’automatisation avec l’api REST , utilisez les informations d’identification fédérées retournées par l’API :

authorization.parameters.workloadIdentityFederationIssuer
authorization.parameters.workloadIdentityFederationSubject

De même, lors de la création d’une connexion de service avec le fournisseur Terraform azuredevops, la ressource azuredevops_serviceendpoint_azurerm retourne workload_identity_federation_issuer et workload_identity_federation_subject attributs.

Plus d’informations

• Se connecter à Azure avec une connexion de service Azure Resource Manager
• Résoudre des problèmes de connexion au service d’identité de charge de travail Azure Resource Manager

tâche Gradle@4

Une nouvelle tâche Gradle@4 a été créée avec prise en charge de Gradle 8.0. L’option prédéfinie de couverture du code est supprimée de la tâche Gradle à partir de Gradle@4. Pour utiliser la couverture du code avec Gradle dans votre pipeline :

• Spécifiez les plug-ins de couverture du code dans votre fichier build.gradle. Pour plus d’informations, consultez les options d’analyse du code Gradle.
• Utilisez la tâche PublishCodeCoverageResults@2 dans votre pipeline après la tâche Gradle@4.

La configuration de l’analyse SonarQube a été déplacée vers les extensions SonarQube ou SonarCloud dans la tâche Prepare Analysis Configuration.

Identité de l’utilisateur qui a demandé une étape à exécuter

Pour améliorer la sécurité de vos pipelines YAML, vous souhaiterez peut-être savoir qui a demandé une étape à exécuter. Pour répondre à ce besoin, ajoutiez deux nouvelles variables prédéfinies, Build.StageRequestedBy et Build.StageRequestedById. Ces variables sont similaires aux variables Build.RequestedFor et Build.RequestedForId, mais pour une étape, pas une exécution.

Lorsqu’un utilisateur déclenche explicitement un utilisateur, par exemple, en cas d’étape déclenchée manuellement ou de réexécution d’une phase, son identité est utilisée pour remplir les deux variables.

Étapes suivantes

Remarque

Ces fonctionnalités seront déployées au cours des deux à trois prochaines semaines.

Accédez à Azure DevOps et jetez un coup d’œil.

Accéder à Azure DevOps

Comment fournir des commentaires

Nous aimerions entendre ce que vous pensez de ces fonctionnalités. Utilisez le menu d’aide pour signaler un problème ou fournir une suggestion.

Vous pouvez également obtenir des conseils et répondre à vos questions par la communauté sur Stack Overflow.