Partager via


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.

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.

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.

    Définir le débogage système sur 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)

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.
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 :
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.
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
Nom de l’environnement 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)

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.

Ajoutez la tentative d'index en tant que paramètre.

Variables d’agent (DevOps Server 2022)

Remarque

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 Server 2022)

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. Cette variable est disponible sur Azure DevOps Server 2022.1 et versions ultérieures. 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 ? ». Oui
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.
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 :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.
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 Server 2022)

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 Server 2022)

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
Nom de l’environnement 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 Server 2022)

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.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. No
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 cet index est tenté et incrémente chaque fois que l’index 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 Server 2022)

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.
Ajoutez la tentative d'index en tant que paramètre.

Variables d’agent (DevOps Server 2020)

Remarque

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.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 processor
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)

Variables de build (DevOps Server 2020)

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.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 de l’étiquette échoue.
Yes
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/&lt;RepoName&gt; 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.
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 :
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.
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.

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 ni 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.
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.
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.
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.
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.
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 Server 2020)

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.

Variables de travail de déploiement (DevOps Server 2020)

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
Nom de l’environnement 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.

Variables système (DevOps Server 2020)

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 collection Team Foundation Server de chaîne. 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.
Non
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.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.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. Yes
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. (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.TeamFoundationCollectionUri URI de la collection de fondations d’équipe. 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
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

Variables d’agent (DevOps Server 2019)

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. Par exemple : c:\agent_work\1.
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 processor
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.
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.

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).

Variables de build (DevOps Server 2019)

Variable Description
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. 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.
Build.BuildId ID de l’enregistrement de la build terminée.
Build.BuildNumber Nom du build terminé. Vous pouvez spécifier le format de numéro de build qui génère cette valeur dans les options de pipeline.

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. 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.
Build.BuildUri URI du build. Par exemple : vstfs:///Build/Build/1430.

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.
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. 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.
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 de l’étiquette échoue.
Build.DefinitionVersion Version du pipeline de build.
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.
Build.QueuedById Consultez « Comment les variables d’identité sont-elles définies ? ».
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.
Consultez Déclencheurs de pipeline de build, Améliorer la qualité du code avec les stratégies de branche.
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. 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.
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.

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.

Cette variable est synonyme de Build.SourcesDirectory.
Build.Repository.Name Nom du 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.
Build.Repository.Provider Type de référentiel que vous avez sélectionné.
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.
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. 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.
Build.Repository.Uri URL du référentiel. Par exemple :
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.
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.
Build.RequestedForEmail Consultez « Comment les variables d’identité sont-elles définies ? ».
Build.RequestedForId Consultez « Comment les variables d’identité sont-elles définies ? ».
Build.SourceBranch Branche pour laquelle 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 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.
Build.SourceBranchName Nom de la branche pour laquelle 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.
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. 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.

Cette variable est synonyme de Build.Repository.LocalPath.
Build.SourceVersion Dernière modification du gestion de version incluse dans ce build.
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.
Build.SourceVersionMessage Commentaire de la validation ou de l’ensemble de modifications. Nous tronquons le message à la première ligne ou à 200 caractères, selon la valeur la plus courte.

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.

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.
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. 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.
Build.Repository.Git.SubmoduleCheckout Valeur que vous avez sélectionnée pour Sous-modules d’extraction 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.
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.
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.

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.
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.

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.
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.

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.
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.

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.
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.

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.
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. 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.

Variables système (DevOps Server 2019)

Exemple de script PowerShell : accéder à l’API REST

Variable Description
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. 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.
System.CollectionId GUID de la collection TFS ou de l’organisation Azure DevOps
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.
System.DefinitionId ID du pipeline de build.
System.HostType Défini sur build si le pipeline est un build. Pour une mise en production, les valeurs sont deployment pour un travail de groupe de déploiement et release pour un travail d’agent.
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.
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.)
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.
System.PullRequest.SourceBranch Branche en cours de révision dans une demande de tirage. Par exemple : refs/heads/users/raisa/new-feature. (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.)
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.)
System.PullRequest.SourceRepositoryURI URL du référentiel qui contient la demande de tirage. Par exemple : https://dev.azure.com/ouraccount/_git/OurProject. (Cette variable est initialisée uniquement si le build s’est exécuté en raison d’une demande de tirage Git Azure Repos affectée par une stratégie de branche. Elle n’est pas initialisée pour les demandes de tirage GitHub.)
System.PullRequest.TargetBranch Branche qui est la cible d’une demande de tirage. Par exemple : refs/heads/main. 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.
System.TeamFoundationCollectionUri URI de la collection de fondations d’équipe. Par exemple : https://dev.azure.com/fabrikamfiber/.

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.
System.TeamProject Nom du projet contenant ce build.
System.TeamProjectId ID du projet auquel appartient ce build.
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. 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.

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