Utiliser des variables prédéfinies

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Les variables sont pratiques pour fournir des bits de données clés dans différentes parties de votre pipeline. Il s’agit d’une liste de variables prédéfinies que vous pouvez utiliser. Il peut y avoir quelques autres variables prédéfinies, mais elles sont principalement réservées à un usage interne.

Ces variables sont automatiquement définies par le système et sont en lecture seule. (Les exceptions sont Build.Clean et System.Debug.)

Dans les pipelines YAML, vous pouvez référencer des variables prédéfinies en tant que variables d’environnement. Par exemple, la variable Build.ArtifactStagingDirectory devient la variable BUILD_ARTIFACTSTAGINGDIRECTORY.

Pour les pipelines classiques, vous pouvez utiliser des variables de mise en production dans vos tâches de déploiement pour partager les informations courantes (par exemple, nom de l’environnement, groupe de ressources, etc.).

En savoir plus sur l’utilisation de variables.

Build.Clean

Il s’agit d’une variable déconseillée qui modifie la façon dont l’agent de build nettoie la source. Pour savoir comment nettoyer la source, consultez Nettoyer le référentiel local sur l’agent.

System.AccessToken

System.AccessToken est une variable spéciale qui porte le jeton de sécurité utilisé par le build en cours d’exécution.

YAML

Dans YAML, vous devez mapper System.AccessToken explicitement dans le pipeline à l’aide d’une variable. Vous pouvez effectuer cette opération au niveau de l’étape ou de la tâche :

steps:
  - script: |
      echo "Using System.AccessToken to authenticate"
      git clone https://$(System.AccessToken)@dev.azure.com/yourorganization/yourproject/_git/yourrepository
    displayName: 'Clone repository using System.AccessToken'
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)

Vous pouvez configurer l’étendue par défaut pour System.AccessToken à l’aide de l’étendue d’autorisation de la tâche de build.

Classique

Vous pouvez autoriser les scripts et les tâches à accéder à System.AccessToken au niveau du travail.

1. Accéder au travail

2. Sous Options supplémentaires, cochez la case Autoriser les scripts à accéder au jeton OAuth.

Cocher cette case laisse également l’ensemble des informations d’identification dans Git afin que vous puissiez exécuter des envois (push) et des tirages (pull) dans vos scripts.

System.Debug

Pour obtenir des journaux plus détaillés pour déboguer les problèmes de pipeline, définissez System.Debug et définissez-le sur true.

1. Modifiez votre pipeline.

2. Sélectionnez Variables.

3. Ajoutez une nouvelle variable avec le nom System.Debug et la valeur true.

   

4. Enregistrez la nouvelle variable.

Définir System.Debug sur true configure des journaux détaillés pour toutes les exécutions. Vous pouvez également configurer des journaux détaillés pour une seule exécution avec la case Activer les diagnostics système.

Vous pouvez également définir System.Debug sur true comme variable dans un pipeline ou un modèle.

variables:
  system.debug: 'true'

Lorsque System.Debug est défini sur true, une variable supplémentaire nommée Agent.Diagnostic est définie sur true. Quand Agent.Diagnostic est true, l’agent collecte davantage de journaux qui peuvent être utilisés pour résoudre les problèmes réseau pour les agents auto-hébergés. Pour plus d’informations, consultez Diagnostics réseau pour les agents auto-hébergés.

Remarque

La variable Agent.Diagnostic est disponible avec Agent v2.200.0 et versions ultérieures.

Pour plus d’informations, consultez Examiner les journaux d’activité pour diagnostiquer les problèmes de pipeline.

Variables d’agent (DevOps Services)

Notes

Vous pouvez utiliser des variables d’agent comme variables d’environnement dans vos scripts et en tant que paramètres dans vos tâches de build. Vous ne pouvez pas les utiliser pour personnaliser le numéro de build ou appliquer une balise ou une étiquette de contrôle de version.

Variable	Description
Agent.BuildDirectory	Chemin d’accès local sur l’agent dans lequel tous les dossiers d’un pipeline de build donné sont créés. Cette variable a la même valeur que Pipeline.Workspace. Par exemple : /home/vsts/work/1.
Agent.ContainerMapping	Mappage des noms de ressources de conteneur dans YAML à leurs ID Docker au moment de l’exécution. L'exemple suit le tableau.
Agent.HomeDirectory	Répertoire dans lequel l’agent est installé. Il contient le logiciel de l’agent. Par exemple : c:\agent.
Agent.Id	ID de l'Agent.
Agent.JobName	Nom du travail en cours d’exécution. Il s’agit généralement de « Travail » ou de « __default », mais dans les scénarios multiconfiguration, il s’agit de la configuration.
Agent.JobStatus	État du build. Canceled Failed Succeeded SucceededWithIssues (partiellement réussi) Skipped (dernier travail) La variable d’environnement doit être référencée en tant que AGENT_JOBSTATUS. L’ancien agent.jobstatus est disponible pour la compatibilité descendante.
Agent.MachineName	Nom de l’ordinateur sur lequel l’agent est installé.
Agent.Name	Nom de l’agent inscrit auprès du pool. Si vous utilisez un agent autohébergé, c’est vous qui spécifiez ce nom. Voir les agents.
Agent.OS	Système d’exploitation de l’hôte de l’agent. Les valeurs autorisées sont : Windows_NT Darwin Linux Si vous exécutez dans un conteneur, l’hôte de l’agent et le conteneur peuvent exécuter différents systèmes d’exploitation.
Agent.OSArchitecture	Architecture du processeur du système d’exploitation de l’hôte de l’agent. Les valeurs autorisées sont : X86 X64 ARM
Agent.TempDirectory	Dossier temporaire nettoyé après chaque travail de pipeline. Ce répertoire est utilisé par des tâches telles que la tâche CLI .NET Core pour contenir des éléments temporaires tels que les résultats des tests avant leur publication. Par exemple : /home/vsts/work/_temp pour Ubuntu.
Agent.ToolsDirectory	Répertoire utilisé par des tâches telles que Programme d’installation de l’outil Node et Utiliser la version de Python pour basculer entre plusieurs versions d’un outil. Ces tâches ajoutent des outils à PATH à partir de ce répertoire pour que les étapes de build suivantes puissent les utiliser. Découvrez comment gérer ce répertoire sur un agent autohébergé.
Agent.WorkFolder	Répertoire de travail de cet agent. Par exemple : c:\agent_work. Note : ce répertoire n’est pas garanti pour être accessible en écriture par les tâches de pipeline (par exemple, lorsqu’il est mappé dans un conteneur)

Exemple d’Agent.ContainerMapping :

{
  "one_container": {
    "id": "bdbb357d73a0bd3550a1a5b778b62a4c88ed2051c7802a0659f1ff6e76910190"
  },
  "another_container": {
    "id": "82652975109ec494876a8ccbb875459c945982952e0a72ad74c91216707162bb"
  }
}

Variables de build (DevOps Services)

Lorsque vous utiliserez dans un modèle une variable qui n'est pas marquée comme étant disponible dans les modèles, celle-ci ne s’affichera pas. La variable ne s’affichera pas, car sa valeur n’est pas accessible dans l’étendue du modèle.

Variable	Description	Disponible dans les modèles ?
Build.ArtifactStagingDirectory	Chemin d’accès local sur l’agent vers lequel tous les artefacts sont copiés avant d’être envoyés (push) à leur destination. Par exemple : c:\agent_work\1\a. Une manière classique d’utiliser ce dossier consiste à publier vos artefacts de build avec les tâches Copier des fichiers et Publier des artefacts de build. Note : Build.ArtifactStagingDirectory et Build.StagingDirectory sont interchangeables. Ce répertoire est vidé avant chaque nouveau build. Vous n’avez donc pas à le nettoyer vous-même. Consultez Artefacts dans Azure Pipelines. Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version.	Non
Build.BuildId	ID de l’enregistrement de la build terminée.	Non
Build.BuildNumber	Nom du build terminé, également appelé numéro d’exécution. Vous pouvez spécifier ce qui est inclus dans cette valeur. Une utilisation classique de cette variable consiste à l’intégrer au format d’étiquette, que vous spécifiez sous l’onglet référentiel. Note : cette valeur peut contenir des espaces blancs ou d’autres caractères d’étiquette non valides. Dans ces cas, le format d’étiquette échoue. Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version.	No
Build.BuildUri	URI du build. Par exemple : vstfs:///Build/Build/1430. Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version.	Non
Build.BinariesDirectory	Chemin d’accès local sur l’agent que vous pouvez utiliser comme dossier de sortie pour les fichiers binaires compilés. Par défaut, les nouveaux pipelines de build ne sont pas configurés pour nettoyer ce répertoire. Vous pouvez définir votre build pour le nettoyer sous l’onglet Référentiel. Par exemple : c:\agent_work\1\b. Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version.	Non
Build.ContainerId	ID du conteneur pour votre artefact. Lorsque vous chargez un artefact dans votre pipeline, il est ajouté à un conteneur spécifique à cet artefact particulier.	Non
Build.CronSchedule.DisplayName	Planification displayName cron qui a déclenché l’exécution du pipeline. Cette variable est définie uniquement si l’exécution du pipeline est déclenchée par un déclencheur de planification YAML. Pour plus d’informations, consultez Définition schedules.cron - variable Build.CronSchedule.DisplayName	Oui
Build.DefinitionName	Nom du pipeline de build. Note : cette valeur peut contenir des espaces blancs ou d’autres caractères d’étiquette non valides. Dans ces cas, le format d’étiquette échoue.	Oui
Build.DefinitionVersion	Version du pipeline de build.	Oui
Build.QueuedBy	Consultez « Comment les variables d’identité sont-elles définies ? ». Note : cette valeur peut contenir des espaces blancs ou d’autres caractères d’étiquette non valides. Dans ces cas, le format d’étiquette échoue.	Oui
Build.QueuedById	Consultez « Comment les variables d’identité sont-elles définies ? ».	Yes
Build.Reason	Événement ayant provoqué l’exécution du build. Manual : un utilisateur a mis le build en file d’attente manuellement. IndividualCI : intégration continue (CI) déclenchée par un envoi Git ou un archivage TFVC. BatchedCI : intégration continue (CI) déclenchée par un envoi Git ou un archivage TFVC, et les modifications batch ont été sélectionnées. Schedule : déclencheur planifié. ValidateShelveset : un utilisateur a mis le build d’un jeu de réservations TFVC spécifique en file d’attente manuellement. CheckInShelveset : déclencheur d’archivage contrôlé. PullRequest : le build a été déclenché par une stratégie de branche Git qui nécessite un build. BuildCompletion : le build a été déclenché par un autre build ResourceTrigger : le build a été déclenché par un déclencheur de ressource ou il a été déclenché par un autre build. Consultez Déclencheurs de pipeline de build, Améliorer la qualité du code avec les stratégies de branche.	Oui
Build.Repository.Clean	Valeur que vous avez sélectionnée pour Nettoyer dans les paramètres du référentiel source. Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version.	Non
Build.Repository.LocalPath	Chemin d’accès local sur l’agent dans lequel vos fichiers de code source sont téléchargés. Par exemple : c:\agent_work\1\s. Par défaut, les nouveaux pipelines de build mettent à jour uniquement les fichiers modifiés. Vous pouvez modifier la façon dont les fichiers sont téléchargés sous l’onglet Référentiel. Remarque importante : si vous n’avez extrait qu’un seul référentiel Git, ce chemin d’accès est le chemin exact du code. Si vous extrayez plusieurs référentiels, le comportement est le suivant (et peut différer de la valeur de la variable Build.SourcesDirectory) : Si l’étape d’extraction du référentiel auto (principal) n’a pas de chemin d’extraction personnalisé défini, ou si le chemin d’extraction est le chemin d’accès par défaut multi-extraction $(Pipeline.Workspace)/s/&<RepoName> pour le référentiel auto, la valeur de cette variable revient à sa valeur par défaut, qui est $(Pipeline.Workspace)/s. Si l’étape d’extraction du référentiel auto (principal) a un chemin d’extraction personnalisé défini (et qu’il ne s’agit pas de son chemin d’accès par défaut multi-extraction), cette variable contient le chemin exact vers le référentiel auto. Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version.	Non
Build.Repository.ID	Identificateur unique du référentiel. Il ne change pas, même si le nom du référentiel change. Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version.	No
Build.Repository.Name	Nom du référentiel déclencheur. Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version.	Non
Build.Repository.Provider	Type du référentiel déclencheur. TfsGit : référentiel Git TFS TfsVersionControl : Team Foundation Version Control Git : référentiel Git hébergé sur un serveur externe GitHub Svn : Subversion Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version.	Non
Build.Repository.Tfvc.Workspace	Défini si votre référentiel est Team Foundation Version Control. Nom de l’espace de travail TFVC utilisé par l’agent de build. Par exemple, si l’Agent.BuildDirectory est c:\agent_work\12 et que l’Agent.Id est 8, le nom de l’espace de travail peut être : ws_12_8 Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version.	No
Build.Repository.Uri	URL du référentiel déclencheur. Par exemple : Git : https://fabrikamfiber@dev.azure.com/fabrikamfiber/_git/Scripts TFVC : https://dev.azure.com/fabrikamfiber/ Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version.	Non
Build.RequestedFor	Consultez « Comment les variables d’identité sont-elles définies ? ». Note : cette valeur peut contenir des espaces blancs ou d’autres caractères d’étiquette non valides. Dans ces cas, le format d’étiquette échoue.	Oui
Build.RequestedForEmail	Consultez « Comment les variables d’identité sont-elles définies ? ».	Yes
Build.RequestedForId	Consultez « Comment les variables d’identité sont-elles définies ? ».	Yes
Build.SourceBranch	La branche du référentiel déclencheur pour lequel le build a été mis en file d’attente. Exemples : Branche de référentiel Git : refs/heads/main Demande de tirage (pull request) de référentiel Git : refs/pull/1/merge Branche de référentiel TFVC : $/teamproject/main Archivage contrôlé de référentiel TFVC : Gated_2016-06-06_05.20.51.4369;username@live.com Build de jeu de réservations du référentiel TFVC : myshelveset;username@live.com Lorsque votre pipeline est déclenché par une balise : refs/tags/your-tag-name Lorsque vous utilisez cette variable dans votre format de numéro de build, les caractères de barre oblique (/) sont remplacés par des caractères de soulignement _). Note : dans TFVC, si vous exécutez un build d’archivage contrôlé ou si vous générez manuellement un jeu de réservations, vous ne pouvez pas utiliser cette variable dans votre format de numéro de build.	Oui
Build.SourceBranchName	Nom de la branche dans le référentiel déclencheur pour lequel le build a été mis en file d’attente. Branche de référentiel Git, demande de tirage (pull request) ou balise : dernier segment de chemin d’accès dans la référence. Par exemple, dans refs/heads/main cette valeur est main. Dans refs/heads/feature/tools cette valeur est tools. Dans refs/tags/your-tag-name cette valeur est your-tag-name. Branche de référentiel TFVC : dernier segment de chemin d’accès dans le chemin du serveur racine de l’espace de travail. Par exemple, dans $/teamproject/main cette valeur est main. L’archivage contrôlé du référentiel TFVC ou le build de jeu de réservations est le nom du jeu de réservations. Par exemple, Gated_2016-06-06_05.20.51.4369;username@live.com ou myshelveset;username@live.com. Note : dans TFVC, si vous exécutez un build d’archivage contrôlé ou si vous générez manuellement un jeu de réservations, vous ne pouvez pas utiliser cette variable dans votre format de numéro de build.	Oui
Build.SourcesDirectory	Chemin d’accès local sur l’agent dans lequel vos fichiers de code source sont téléchargés. Par exemple : c:\agent_work\1\s. Par défaut, les nouveaux pipelines de build mettent à jour uniquement les fichiers modifiés. Remarque importante : si vous n’avez extrait qu’un seul référentiel Git, ce chemin d’accès est le chemin exact du code. Si vous extrayez plusieurs référentiels, il rétablit sa valeur par défaut, c’est-à-dire $(Pipeline.Workspace)/s, même si le référentiel auto (principal) est extrait vers un chemin d’accès personnalisé différent de son chemin d’accès par défaut multi-extraction $(Pipeline.Workspace)/s/<RepoName> (à cet égard, la variable diffère du comportement de la variable Build.Repository.LocalPath). Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version.	Non
Build.SourceVersion	Dernière modification du contrôle de version du référentiel déclencheur inclus dans ce build. Git : ID de validation. TFVC : ensemble de modifications. Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version.	Yes
Build.SourceVersionMessage	Commentaire de validation ou d’ensemble de modifications du référentiel déclencheur. Nous tronquons le message à la première ligne ou à 200 caractères, selon la valeur la plus courte. Build.SourceVersionMessage correspond au message de la validation Build.SourceVersion. La validation Build.SourceVersion d’un build de demande de tirage (pull request) est la validation de fusion (et non la validation sur la branche source). Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version. En outre, cette variable est disponible uniquement au niveau de l’étape et n’est pas disponible dans le travail ni dans les niveaux d’index (c’est-à-dire que le message n’est pas extrait tant que le travail n’a pas démarré et extrait le code). Note : cette variable est disponible dans TFS 2015.4. Note : la variable Build.SourceVersionMessage ne fonctionne pas avec pipelines de build dans les référentiels Bitbucket quand l’option Changements par lots durant un processus de génération est activée.	Non
Build.StagingDirectory	Chemin d’accès local sur l’agent vers lequel tous les artefacts sont copiés avant d’être envoyés (push) à leur destination. Par exemple : c:\agent_work\1\a. Une manière classique d’utiliser ce dossier consiste à publier vos artefacts de build avec les tâches Copier des fichiers et Publier des artefacts de build. Note : Build.ArtifactStagingDirectory et Build.StagingDirectory sont interchangeables. Ce répertoire est vidé avant chaque nouveau build. Vous n’avez donc pas à le nettoyer vous-même. Consultez Artefacts dans Azure Pipelines. Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version.	Non
Build.Repository.Git.SubmoduleCheckout	Valeur que vous avez sélectionnée pour Sous-modules d’extraction sous l’onglet Référentiel. Avec plusieurs référentiels extraits, cette valeur suit le paramètre du référentiel déclencheur. Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version.	No
Build.SourceTfvcShelveset	Défini si votre référentiel est Team Foundation Version Control. Si vous exécutez un build contrôlé ou un build de jeu de réservations, il est défini sur le nom du jeu de réservations que vous générez. Note : cette variable génère une valeur non valide pour l’utilisation de build dans un format de numéro de build.	No
Build.TriggeredBy.BuildId	Si le build a été déclenché par un autre build, cette variable est définie sur BuildID du build de déclenchement. Dans les pipelines classiques, cette variable est déclenchée par un déclencheur d’achèvement de build. Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version. Si vous déclenchez un pipeline YAML à l’aide de resources, vous devez utiliser les variables de ressources à la place.	Non
Build.TriggeredBy.DefinitionId	Si le build a été déclenché par un autre build, cette variable est définie sur DefinitionID du build de déclenchement. Dans les pipelines classiques, cette variable est déclenchée par un déclencheur d’achèvement de build. Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version. Si vous déclenchez un pipeline YAML à l’aide de resources, vous devez utiliser les variables de ressources à la place.	Non
Build.TriggeredBy.DefinitionName	Si le build a été déclenché par un autre build, cette variable est définie sur le nom du pipeline de build de déclenchement. Dans les pipelines classiques, cette variable est déclenchée par un déclencheur d’achèvement de build. Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version. Si vous déclenchez un pipeline YAML à l’aide de resources, vous devez utiliser les variables de ressources à la place.	Non
Build.TriggeredBy.BuildNumber	Si le build a été déclenché par un autre build, cette variable est définie sur le nombre de builds de déclenchement. Dans les pipelines classiques, cette variable est déclenchée par un déclencheur d’achèvement de build. Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version. Si vous déclenchez un pipeline YAML à l’aide de resources, vous devez utiliser les variables de ressources à la place.	Non
Build.TriggeredBy.ProjectID	Si le build a été déclenché par un autre build, cette variable est définie sur l’ID du projet qui contient le build de déclenchement. Dans les pipelines classiques, cette variable est déclenchée par un déclencheur d’achèvement de build. Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version. Si vous déclenchez un pipeline YAML à l’aide de resources, vous devez utiliser les variables de ressources à la place.	Non
Common.TestResultsDirectory	Chemin d’accès local sur l’agent dans lequel les résultats du test sont créés. Par exemple : c:\agent_work\1\TestResults. Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version.	Non

Variables de pipeline (DevOps Services)

Variable	Description
Pipeline.Workspace	Répertoire de l’espace de travail pour un pipeline particulier. Cette variable a la même valeur que Agent.BuildDirectory. Par exemple : /home/vsts/work/1.

Conseil

Si vous utilisez des pipelines de mise en production classiques, vous pouvez utiliser des variables de mise en production et d’artefacts classiques pour stocker et accéder aux données dans votre pipeline.

Variables de travail de déploiement (DevOps Services)

Ces variables sont étendues à un travail de déploiement spécifique et sont résolues uniquement au moment de l’exécution du travail.

Variable	Description
Environment.Name	Nom de l’environnement ciblé dans le travail de déploiement pour exécuter les étapes de déploiement et enregistrer l’historique du déploiement. Par exemple : smarthotel-dev.
Environment.Id	ID de l’environnement ciblé dans le travail de déploiement. Par exemple : 10.
Environment.ResourceName	Nom de la ressource spécifique dans l’environnement ciblé dans le travail de déploiement pour exécuter les étapes de déploiement et enregistrer l’historique de déploiement. Par exemple, bookings, qui est un espace de noms Kubernetes qui a été ajouté en tant que ressource à l’environnement smarthotel-dev.
Environment.ResourceId	ID de la ressource spécifique dans l’environnement ciblé dans le travail de déploiement pour exécuter les étapes de déploiement. Par exemple : 4.
Strategy.Name	Nom de la stratégie de déploiement : canary, runOnce ou rolling.
Strategy.CycleName	Nom du cycle actuel dans un déploiement. Les options sont PreIteration, Iteration ou PostIteration.

Variables système (DevOps Services)

Lorsque vous utiliserez dans un modèle une variable qui n'est pas marquée comme étant disponible dans les modèles, celle-ci ne s’affichera pas. La variable ne s’affichera pas, car sa valeur n’est pas accessible dans l’étendue du modèle.

Variable	Description	Disponible dans les modèles ?
System.AccessToken	Utilisez le jeton OAuth pour accéder à l’API REST. Utilisez System.AccessToken à partir de scripts YAML. Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version.	Yes
System.CollectionId	GUID de la collection TFS ou de l’organisation Azure DevOps.	Yes
System.CollectionUri	URI de la collection TFS ou de l’organisation Azure DevOps. Par exemple : https://dev.azure.com/fabrikamfiber/.	Oui
System.DefaultWorkingDirectory	Chemin d’accès local sur l’agent dans lequel vos fichiers de code source sont téléchargés. Par exemple : c:\agent_work\1\s Par défaut, les nouveaux pipelines de build mettent à jour uniquement les fichiers modifiés. Vous pouvez modifier la façon dont les fichiers sont téléchargés sous l’onglet Référentiel. Cette variable est étendue à l’agent. Elle peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version.	Oui
System.DefinitionId	ID du pipeline de build.	Oui
System.HostType	Défini sur build si le pipeline est un build. Pour une version, les valeurs sont deployment pour un travail de groupe de déploiement, gates pendant l’évaluation des portes et release pour d’autres travaux (agent et sans agent).	Oui
System.JobAttempt	Définit la valeur 1 la première fois que ce travail est tenté et incrémente chaque fois que le travail est retenté.	Non
System.JobDisplayName	Nom lisible par l’homme donné à un travail.	Non
System.JobId	Identificateur unique pour une seule tentative d’un seul travail. La valeur est unique au pipeline actuel.	Non
System.JobName	Nom du travail, généralement utilisé pour exprimer des dépendances et accéder aux variables de sortie.	Non
System.OidcRequestUri	Génère un idToken pour une authentification avec Entra ID à partir d’OpenID Connect (OIDC). Plus d’informations	Oui
System.PhaseAttempt	Définit la valeur sur 1 la première fois que cette phase est tentée et incrémente chaque fois que le travail est retenté. Note : « Phase » est un concept principalement redondant qui représente le moment de la conception d’un travail (alors que le travail était la version runtime d’une phase). Nous avons principalement supprimé le concept de « phase » d’Azure Pipelines. Les travaux de matrice et multiconfiguration sont le seul endroit où « phase » est toujours distinct de « travail ». Une phase peut instancier plusieurs travaux, qui diffèrent uniquement dans leurs entrées.	Non
System.PhaseDisplayName	Nom lisible par l’homme donné à une phase.	Non
System.PhaseName	Identificateur basé sur des chaînes pour un travail, généralement utilisé pour exprimer des dépendances et accéder aux variables de sortie.	Non
System.PlanId	Identificateur basé sur des chaînes pour une seule exécution de pipeline.	Non
System.PullRequest.IsFork	Si la demande de tirage (pull request) provient d’une duplication (fork) du référentiel, cette variable est définie sur True. Sinon, elle est définie sur False.	Oui
System.PullRequest.PullRequestId	ID de la demande de tirage (pull request) qui a provoqué ce build. Par exemple : 17. (Cette variable est initialisée uniquement si le build s’est exécuté en raison d’une demande de tirage Git affectée par une stratégie de branche).	No
System.PullRequest.PullRequestNumber	Nombre de la demande de tirage (pull request) qui a provoqué ce build. Cette variable est remplie pour les demandes de tirage (pull request) à partir de GitHub qui ont un ID de demande de tirage et un numéro de demande de tirage différents. Cette variable est disponible uniquement dans un pipeline YAML si la demande de tirage est affectée par une stratégie de branche.	Non
System.PullRequest.targetBranchName	Nom de la branche cible pour une demande de tirage. Cette variable peut être utilisée dans un pipeline pour exécuter des tâches ou des étapes de manière conditionnelle en fonction de la branche cible de la demande de tirage. Par exemple, vous pouvez déclencher un autre ensemble de tests ou d’outils d’analyse de code en fonction de la branche dans laquelle les modifications sont fusionnées.	Non
System.PullRequest.SourceBranch	Branche en cours de révision dans une demande de tirage. Par exemple : refs/heads/users/raisa/new-feature pour Azure Repos. (Cette variable est initialisée uniquement si le build s’est exécuté en raison d’une demande de tirage Git affectée par une stratégie de branche). Cette variable est disponible uniquement dans un pipeline YAML si la demande de tirage est affectée par une stratégie de branche.	Non
System.PullRequest.SourceCommitId	Validation en cours de révision dans une demande de tirage. (Cette variable est initialisée uniquement si le build s’est exécuté en raison d’une demande de tirage Git affectée par une stratégie de branche). Cette variable est disponible uniquement dans un pipeline YAML si la demande de tirage est affectée par une stratégie de branche.
System.PullRequest.SourceRepositoryURI	URL du référentiel qui contient la demande de tirage. Par exemple : https://dev.azure.com/ouraccount/_git/OurProject.	Non
System.PullRequest.TargetBranch	Branche qui est la cible d’une demande de tirage. Par exemple : refs/heads/main lorsque votre référentiel se trouve dans Azure Repos et main quand votre référentiel se trouve dans GitHub. Cette variable est initialisée uniquement si le build s’est exécuté en raison d’une demande de tirage Git affectée par une stratégie de branche. Cette variable est disponible uniquement dans un pipeline YAML si la demande de tirage est affectée par une stratégie de branche.	Non
System.StageAttempt	Définit la valeur sur 1 la première fois que cette étape est tentée et incrémente chaque fois que le travail est retenté.	Non
System.StageDisplayName	Nom lisible par l’homme donné à une étape.	Non
System.StageName	Identificateur basé sur des chaînes pour une étape, généralement utilisé pour exprimer des dépendances et accéder aux variables de sortie.	Non
System.TeamFoundationCollectionUri	URI de la collection TFS ou de l’organisation Azure DevOps. Par exemple : https://dev.azure.com/fabrikamfiber/. Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version.	Yes
System.TeamProject	Nom du projet contenant ce build.	Yes
System.TeamProjectId	ID du projet auquel appartient ce build.	Yes
System.TimelineId	Identificateur basé sur des chaînes pour les détails d’exécution et les journaux d’une seule exécution de pipeline.	Non
TF_BUILD	Définit la valeur sur True si le script est exécuté par une tâche de build. Cette variable est étendue à l’agent et peut être utilisée comme variable d’environnement dans un script et comme paramètre dans une tâche de build, mais pas dans le cadre du numéro de build ou comme balise de contrôle de version.	Non

Vérifie les variables (DevOps Services)

Variable	Description
Checks.StageAttempt	Définit la valeur sur 1 la première fois que cet index est tenté et incrémente chaque fois que l’index est retenté. Cette variable peut uniquement être utilisée dans une approbation ou vérification pour un environnement. Par exemple, vous pouvez utiliser $(Checks.StageAttempt) dans une vérification de l’API REST Invoke.

Comment les variables d’identité sont-elles définies ?

La valeur dépend de ce qui a provoqué le build et qui est spécifique aux référentiels Azure Repos.

Si le build est déclenché...	Les valeurs Build.QueuedBy et Build.QueuedById sont ensuite basées sur...	Les valeurs Build.RequestedFor et Build.RequestedForId sont ensuite basées sur...
Dans Git ou par les déclencheurs d’intégration continue (CI)	L’identité système, par exemple : [DefaultCollection]\Project Collection Service Accounts	Personne qui a envoyé ou archivé les modifications.
Dans Git ou par un build de stratégie de branche.	L’identité système, par exemple : [DefaultCollection]\Project Collection Service Accounts	Personne qui a archivé les modifications.
Dans TFVC par un déclencheur d’archivage contrôlé	Personne qui a archivé les modifications.	Personne qui a archivé les modifications.
Dans Git ou TFVC par les déclencheurs planifiés	L’identité système, par exemple : [DefaultCollection]\Project Collection Service Accounts	L’identité système, par exemple : [DefaultCollection]\Project Collection Service Accounts
Parce que vous avez cliqué sur le bouton Mettre le build en file d’attente	Vous	Vous