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
.
Modifiez votre pipeline.
Sélectionnez Variables.
Ajoutez une nouvelle variable avec le nom
System.Debug
et la valeurtrue
.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.
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 :
|
Agent.OSArchitecture | Architecture du processeur du système d’exploitation de l’hôte de l’agent. Les valeurs autorisées sont :
|
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.
|
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) :
|
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.
|
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 :
/ ) 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.
|
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.
|
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.![]() |
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.
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 :
|
Agent.OSArchitecture | Architecture du processeur du système d’exploitation de l’hôte de l’agent. Les valeurs autorisées sont :
|
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.
|
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) :
|
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.
|
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 :
/ ) 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.
|
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.
|
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. ![]() |
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.
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 :
|
Agent.OSArchitecture | Architecture du processeur du système d’exploitation de l’hôte de l’agent. Les valeurs autorisées sont :
|
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.
|
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) :
|
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.
|
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 :
/ ) 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.
|
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.
|
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.
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 :
|
Agent.OSArchitecture | Architecture du processeur du système d’exploitation de l’hôte de l’agent. Les valeurs autorisées sont :
|
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.
|
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é.
|
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 :
/ ) 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.
|
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.
|
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 |