Vooraf gedefinieerde variabelen gebruiken

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

Variabelen zijn een handige manier om belangrijke stukjes gegevens in verschillende delen van uw pijplijn te introduceren. Dit is een lijst met vooraf gedefinieerde variabelen die u kunt gebruiken. Er kunnen enkele andere vooraf gedefinieerde variabelen zijn, maar ze zijn meestal voor intern gebruik.

Deze variabelen worden automatisch ingesteld door het systeem en alleen-lezen. (De uitzonderingen zijn Build.Clean en System.Debug.)

In YAML-pijplijnen kunt u verwijzen naar vooraf gedefinieerde variabelen als omgevingsvariabelen. De variabele wordt bijvoorbeeld de variabele Build.ArtifactStagingDirectoryBUILD_ARTIFACTSTAGINGDIRECTORY.

Voor klassieke pijplijnen kunt u releasevariabelen in uw implementatietaken gebruiken om de algemene informatie te delen (bijvoorbeeld omgevingsnaam, resourcegroep, enzovoort).

Meer informatie over het werken met variabelen.

Build.Clean

Dit is een afgeschafte variabele die wijzigt hoe de buildagent de bron opschoont. Zie De lokale opslagplaats op de agent opschonen voor meer informatie over het opschonen van de bron.

System.AccessToken

System.AccessToken is een speciale variabele die het beveiligingstoken draagt dat wordt gebruikt door de actieve build.

YAML

In YAML moet u expliciet toewijzen System.AccessToken aan de pijplijn met behulp van een variabele. U kunt dit doen op stap- of taakniveau:

steps:
  - bash: echo This script could use $SYSTEM_ACCESSTOKEN
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)
  - powershell: | 
      Write-Host "This is a script that could use $env:SYSTEM_ACCESSTOKEN"
      Write-Host "$env:SYSTEM_ACCESSTOKEN = $(System.AccessToken)"
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)

U kunt het standaardbereik configureren voor System.AccessToken het gebruik van het autorisatiebereik voor buildtaken.

Klassiek

U kunt scripts en taken toegang geven tot System.AccessToken op taakniveau.

1. Naar de taak navigeren

2. Schakel onder Aanvullende opties het selectievakje Scripts toestaan in voor toegang tot het OAuth-token .

Als u dit selectievakje uitschakelt, blijft de referentiesset ook in Git ingesteld, zodat u pushes en pulls in uw scripts kunt uitvoeren.

System.Debug

Voor gedetailleerdere logboeken voor het opsporen van problemen met pijplijnen, definieert System.Debug en stelt u deze in op true.

1. Bewerk uw pijplijn.

2. Selecteer Variabelen.

3. Voeg een nieuwe variabele toe met de naam System.Debug en waarde true.

   

4. Sla de nieuwe variabele op.

Instelling System.Debug voor true het configureren van uitgebreide logboeken voor alle uitvoeringen. U kunt uitgebreide logboeken ook configureren voor één uitvoering met het selectievakje Systeemdiagnose inschakelen.

U kunt ook instellen System.Debugtrue als een variabele in een pijplijn of sjabloon.

variables:
  system.debug: 'true'

Wanneer System.Debug deze is ingesteld trueop , wordt een extra variabele met de naam Agent.Diagnostic ingesteld op true. Wanneer Agent.Diagnostic is true, verzamelt de agent meer logboeken die kunnen worden gebruikt voor het oplossen van netwerkproblemen voor zelf-hostende agents. Zie Netwerkdiagnose voor zelf-hostende agents voor meer informatie.

Notitie

De Agent.Diagnostic variabele is beschikbaar met Agent v2.200.0 en hoger.

Zie Logboeken controleren om problemen met pijplijnen vast te stellen voor meer informatie.

Agentvariabelen (DevOps Services)

Notitie

U kunt agentvariabelen gebruiken als omgevingsvariabelen in uw scripts en als parameters in uw buildtaken. U kunt ze niet gebruiken om het buildnummer aan te passen of om een versiebeheerlabel of -tag toe te passen.

Variabele	Beschrijving
Agent.BuildDirectory	Het lokale pad op de agent waar alle mappen voor een bepaalde build-pijplijn worden gemaakt. Deze variabele heeft dezelfde waarde als Pipeline.Workspace. Voorbeeld: /home/vsts/work/1.
Agent.ContainerMapping	Een toewijzing van containerresourcenamen in YAML aan hun Docker-id's tijdens runtime. Voorbeeld volgt de tabel.
Agent.HomeDirectory	De map waarin de agent is geïnstalleerd. Dit bevat de agentsoftware. Voorbeeld: c:\agent.
Agent.Id	De id van de agent.
Agent.JobName	De naam van de actieve taak. Dit is meestal 'Job'; of '__default', maar in scenario's met meerdere configuraties is dit de configuratie.
Agent.JobStatus	De status van de build. Canceled Failed Succeeded SucceededWithIssues (gedeeltelijk geslaagd) Naar de omgevingsvariabele moet worden verwezen als AGENT_JOBSTATUS. De oudere agent.jobstatus versie is beschikbaar voor compatibiliteit met eerdere versies.
Agent.MachineName	De naam van de computer waarop de agent is geïnstalleerd.
Agent.Name	De naam van de agent die is geregistreerd bij de pool. Als u een zelf-hostende agent gebruikt, wordt deze naam door u opgegeven. Zie agents.
Agent.OS	Het besturingssysteem van de agenthost. Geldige waarden zijn: Windows_NT Darwin Linux Als u in een container werkt, worden op de host en container van de agent mogelijk verschillende besturingssystemen uitgevoerd.
Agent.OSArchitecture	De processorarchitectuur van het besturingssysteem van de agenthost. Geldige waarden zijn: X86 X64 ARM
Agent.TempDirectory	Een tijdelijke map die na elke pijplijntaak wordt opgeschoond. Deze map wordt gebruikt door taken zoals .NET Core CLI-taak voor het opslaan van tijdelijke items, zoals testresultaten voordat ze worden gepubliceerd. Bijvoorbeeld: /home/vsts/work/_temp voor Ubuntu.
Agent.ToolsDirectory	De map die wordt gebruikt door taken zoals Node Tool Installer en Python-versie gebruiken om te schakelen tussen meerdere versies van een hulpprogramma. Met deze taken worden hulpprogramma's uit deze map toegevoegd, PATH zodat de volgende buildstappen deze kunnen gebruiken. Meer informatie over het beheren van deze map op een zelf-hostende agent.
Agent.WorkFolder	De werkmap voor deze agent. Voorbeeld: c:\agent_work. Opmerking: Deze map is niet gegarandeerd beschrijfbaar door pijplijntaken (bijvoorbeeld wanneer deze is toegewezen aan een container)

Voorbeeld van Agent.ContainerMapping:

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

Variabelen bouwen (DevOps Services)

Variabele	Beschrijving	Beschikbaar in sjablonen?
Build.ArtifactStagingDirectory	Het lokale pad op de agent waarnaar artefacten worden gekopieerd voordat ze naar hun bestemming worden gepusht. Voorbeeld: c:\agent_work\1\a. Een typische manier om deze map te gebruiken, is door uw buildartefacten te publiceren met de taken Voor het kopiëren en publiceren van buildartefacten . Opmerking: Build.ArtifactStagingDirectory en Build.StagingDirectory zijn verwisselbaar. Deze map wordt verwijderd voor elke nieuwe build, dus u hoeft deze niet zelf op te schonen. Bekijk artefacten in Azure Pipelines. Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag.	Nee
Build.BuildId	De id van de record voor de voltooide build.	Nee
Build.BuildNumber	De naam van de voltooide build, ook wel bekend als het uitvoeringsnummer. U kunt opgeven wat is opgenomen in deze waarde. Een typisch gebruik van deze variabele is het maken van het onderdeel van de labelindeling, die u opgeeft op het tabblad Opslagplaats. Opmerking: deze waarde kan spaties of andere ongeldige labeltekens bevatten. In deze gevallen mislukt de labelindeling . Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag.	Nee
Build.BuildUri	De URI voor de build. Voorbeeld: vstfs:///Build/Build/1430. Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag.	Nee
Build.BinariesDirectory	Het lokale pad op de agent kunt u gebruiken als uitvoermap voor gecompileerde binaire bestanden. Nieuwe build-pijplijnen zijn standaard niet ingesteld om deze map op te schonen. U kunt uw build definiëren om deze op te schonen op het tabblad Opslagplaats. Voorbeeld: c:\agent_work\1\b. Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag.	Nee
Build.ContainerId	De id van de container voor uw artefact. Wanneer u een artefact in uw pijplijn uploadt, wordt het toegevoegd aan een container die specifiek is voor dat specifieke artefact.	Nee
Build.CronSchedule.DisplayName	Het displayName cron-schema dat de pijplijnuitvoering heeft geactiveerd. Deze variabele wordt alleen ingesteld als de pijplijnuitvoering wordt geactiveerd door een YAML-geplande trigger. Zie schedules.cron definition - Build.CronSchedule.DisplayName variable	Ja
Build.DefinitionName	De naam van de build-pijplijn. Opmerking: deze waarde kan spaties of andere ongeldige labeltekens bevatten. In deze gevallen mislukt de labelindeling .	Ja
Build.DefinitionVersion	De versie van de build-pijplijn.	Ja
Build.QueuedBy	Zie 'Hoe worden de identiteitsvariabelen ingesteld?' weergegeven. Opmerking: deze waarde kan spaties of andere ongeldige labeltekens bevatten. In deze gevallen mislukt de labelindeling .	Ja
Build.QueuedById	Zie 'Hoe worden de identiteitsvariabelen ingesteld?' weergegeven.	Ja
Build.Reason	De gebeurtenis waardoor de build werd uitgevoerd. Manual: Een gebruiker heeft de build handmatig in de wachtrij geplaatst. IndividualCI: Continue integratie (CI) geactiveerd door een Git-push of een TFVC-check-in. BatchedCI: Continue integratie (CI) geactiveerd door een Git-push of een TFVC-check-in en de Batch-wijzigingen zijn geselecteerd. Schedule: Geplande trigger. ValidateShelveset: Een gebruiker heeft de bouw van een specifieke TFVC-plankenset handmatig in de wachtrij geplaatst. CheckInShelveset: Gated check-in trigger. PullRequest: De build is geactiveerd door een Git-vertakkingsbeleid waarvoor een build is vereist. BuildCompletion: De build is geactiveerd door een andere build ResourceTrigger: De build is geactiveerd door een resourcetrigger of is geactiveerd door een andere build. Zie Build-pijplijntriggers, Codekwaliteit verbeteren met vertakkingsbeleid.	Ja
Build.Repository.Clean	De waarde die u hebt geselecteerd voor Opschonen in de instellingen van de bronopslagplaats. Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag.	Nee
Build.Repository.LocalPath	Het lokale pad op de agent waar uw broncodebestanden worden gedownload. Voorbeeld: c:\agent_work\1\s. Nieuwe build-pijplijnen werken standaard alleen de gewijzigde bestanden bij. U kunt wijzigen hoe bestanden worden gedownload op het tabblad Opslagplaats. Belangrijke opmerking: als u slechts één Git-opslagplaats uitcheckt, is dit pad het exacte pad naar de code. Als u meerdere opslagplaatsen uitcheckt, is het gedrag als volgt (en kan afwijken van de waarde van de variabele Build.SourcesDirectory): Als in de stap voor uitchecken voor de zelfopslagplaats (primaire opslagplaats) geen aangepast uitgecheckt pad is gedefinieerd of als het uitcheckpad het standaardpad $(Pipeline.Workspace)/s/&<RepoName> voor de zelfopslagplaats is, wordt de waarde van deze variabele teruggezet naar de standaardwaarde. Dit is $(Pipeline.Workspace)/s. Als in de stap voor uitchecken voor de zelfopslagplaats (primaire) wel een aangepast uitcheckpad is gedefinieerd (en dit niet het standaardpad voor meervoudige betaling is), bevat deze variabele het exacte pad naar de zelfopslagplaats. Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag.	Nee
Build.Repository.ID	De unieke id van de opslagplaats. Dit verandert niet, zelfs niet als de naam van de opslagplaats dat wel doet. Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag.	Nee
Build.Repository.Name	De naam van de triggerende opslagplaats. Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag.	Nee
Build.Repository.Provider	Het type triggeropslagplaats. TfsGit: TFS Git-opslagplaats TfsVersionControl: Team Foundation-versiebeheer Git: Git-opslagplaats die wordt gehost op een externe server GitHub Svn:Subversion Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag.	Nee
Build.Repository.Tfvc.Workspace	Gedefinieerd als uw opslagplaats Team Foundation Version Control is. De naam van de TFVC-werkruimte die wordt gebruikt door de buildagent. Als de agent.BuildDirectory bijvoorbeeld is c:\agent_work\12 en de Agent.Id is 8, kan de naam van de werkruimte het volgende zijn: ws_12_8 Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag.	Nee
Build.Repository.Uri	De URL voor de triggerende opslagplaats. Voorbeeld: Git: https://fabrikamfiber@dev.azure.com/fabrikamfiber/_git/Scripts TFVC: https://dev.azure.com/fabrikamfiber/ Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag.	Nee
Build.RequestedFor	Zie 'Hoe worden de identiteitsvariabelen ingesteld?' weergegeven. Opmerking: deze waarde kan spaties of andere ongeldige labeltekens bevatten. In deze gevallen mislukt de labelindeling .	Ja
Build.RequestedForEmail	Zie 'Hoe worden de identiteitsvariabelen ingesteld?' weergegeven.	Ja
Build.RequestedForId	Zie 'Hoe worden de identiteitsvariabelen ingesteld?' weergegeven.	Ja
Build.SourceBranch	De vertakking van de triggerende opslagplaats waarvoor de build in de wachtrij is geplaatst. Een aantal voorbeelden: Git-opslagplaatsvertakking: refs/heads/main Pull-aanvraag voor Git-opslagplaats: refs/pull/1/merge TFVC-opslagplaatsvertakking: $/teamproject/main Inchecken via TFVC-opslagplaats: Gated_2016-06-06_05.20.51.4369;username@live.com TFVC-opslagplaats plankenset build: myshelveset;username@live.com Wanneer uw pijplijn wordt geactiveerd door een tag: refs/tags/your-tag-name Wanneer u deze variabele gebruikt in de notatie van het buildnummer, worden de slashtekens (/) vervangen door onderstrepingstekens _). Opmerking: als u in TFVC een gated check-in build uitvoert of handmatig een plankenset bouwt, kunt u deze variabele niet gebruiken in de notatie van het buildnummer.	Ja
Build.SourceBranchName	De naam van de vertakking in de triggerende opslagplaats waarvoor de build in de wachtrij is geplaatst. Git-opslagplaatsvertakking, pull-aanvraag of tag: het laatste padsegment in de ref. In deze waarde is maindit bijvoorbeeld refs/heads/main . In refs/heads/feature/tools deze waarde is tools. In refs/tags/your-tag-name deze waarde is your-tag-name. TFVC-opslagplaatsvertakking: het laatste padsegment in het hoofdserverpad voor de werkruimte. In deze waarde is maindit bijvoorbeeld $/teamproject/main . TFVC-repo gated check-in of plankenset build is de naam van de plankenset. Bijvoorbeeld Gated_2016-06-06_05.20.51.4369;username@live.com of myshelveset;username@live.com. Opmerking: als u in TFVC een gated check-in build uitvoert of handmatig een plankenset bouwt, kunt u deze variabele niet gebruiken in de notatie van het buildnummer.	Ja
Build.SourcesDirectory	Het lokale pad op de agent waar uw broncodebestanden worden gedownload. Voorbeeld: c:\agent_work\1\s. Nieuwe build-pijplijnen werken standaard alleen de gewijzigde bestanden bij. Belangrijke opmerking: als u slechts één Git-opslagplaats uitcheckt, is dit pad het exacte pad naar de code. Als u meerdere opslagplaatsen uitcheckt, wordt deze teruggezet naar de standaardwaarde, namelijk, zelfs $(Pipeline.Workspace)/sals de zelfopslagplaats (primaire) is uitgecheckt naar een aangepast pad dat afwijkt van het standaardpad $(Pipeline.Workspace)/s/<RepoName> voor meervoudige betaling (in dit opzicht verschilt de variabele van het gedrag van de variabele Build.Repository.LocalPath). Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag.	Nee
Build.SourceVersion	De meest recente versiebeheerwijziging van de triggerende opslagplaats die is opgenomen in deze build. Git: de doorvoer-id . TFVC: de wijzigingenset. Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag.	Ja
Build.SourceVersionMessage	De opmerking van de doorvoer of wijzigingenset voor de triggerende opslagplaats. Het bericht wordt afgekapt tot de eerste regel of 200 tekens, afhankelijk van wat korter is. De Build.SourceVersionMessage komt overeen met het bericht bij Build.SourceVersion doorvoer. De Build.SourceVersion doorvoer voor een PULL-build is de samenvoegdoorvoering (niet de doorvoering in de bronbranch). Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag. Deze variabele is ook alleen beschikbaar op stapniveau en is niet beschikbaar in de taak- of faseniveaus (het bericht wordt dus pas geëxtraheerd nadat de taak is gestart en de code is uitgecheckt). Opmerking: deze variabele is beschikbaar in TFS 2015.4. Opmerking: de variabele Build.SourceVersionMessage werkt niet met klassieke build-pijplijnen in Bitbucket-opslagplaatsen wanneer Batch wordt gewijzigd terwijl een build wordt uitgevoerd , is ingeschakeld.	Nee
Build.StagingDirectory	Het lokale pad op de agent waarnaar artefacten worden gekopieerd voordat ze naar hun bestemming worden gepusht. Voorbeeld: c:\agent_work\1\a. Een typische manier om deze map te gebruiken, is door uw buildartefacten te publiceren met de taken Voor het kopiëren en publiceren van buildartefacten . Opmerking: Build.ArtifactStagingDirectory en Build.StagingDirectory zijn verwisselbaar. Deze map wordt verwijderd voor elke nieuwe build, dus u hoeft deze niet zelf op te schonen. Bekijk artefacten in Azure Pipelines. Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag.	Nee
Build.Repository.Git.SubmoduleCheckout	De waarde die u hebt geselecteerd voor uitgecheckte submodules op het tabblad Opslagplaats. Wanneer meerdere opslagplaatsen zijn uitgecheckt, houdt deze waarde de instelling van de triggerende opslagplaats bij. Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag.	Nee
Build.SourceTfvcShelveset	Gedefinieerd als uw opslagplaats Team Foundation Version Control is. Als u een gated build of een plankenset bouwt, is dit ingesteld op de naam van de plankenset die u bouwt. Opmerking: Deze variabele levert een waarde op die ongeldig is voor buildgebruik in een buildnummernotatie.	Nee
Build.TriggeredBy.BuildId	Als de build is geactiveerd door een andere build, wordt deze variabele ingesteld op de BuildID van de triggerende build. In klassieke pijplijnen wordt deze variabele geactiveerd door een trigger voor het voltooien van de build. Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag. Als u een YAML-pijplijn activeert met behulp van resources, moet u in plaats daarvan de resourcevariabelen gebruiken.	Nee
Build.TriggeredBy.DefinitionId	Als de build is geactiveerd door een andere build, wordt deze variabele ingesteld op de DefinitionID van de triggerende build. In klassieke pijplijnen wordt deze variabele geactiveerd door een trigger voor het voltooien van de build. Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag. Als u een YAML-pijplijn activeert met behulp van resources, moet u in plaats daarvan de resourcevariabelen gebruiken.	Nee
Build.TriggeredBy.DefinitionName	Als de build is geactiveerd door een andere build, wordt deze variabele ingesteld op de naam van de triggerende build-pijplijn. In klassieke pijplijnen wordt deze variabele geactiveerd door een trigger voor het voltooien van de build. Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag. Als u een YAML-pijplijn activeert met behulp van resources, moet u in plaats daarvan de resourcevariabelen gebruiken.	Nee
Build.TriggeredBy.BuildNumber	Als de build is geactiveerd door een andere build, wordt deze variabele ingesteld op het nummer van de triggerende build. In klassieke pijplijnen wordt deze variabele geactiveerd door een trigger voor het voltooien van de build. Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag. Als u een YAML-pijplijn activeert met behulp van resources, moet u in plaats daarvan de resourcevariabelen gebruiken.	Nee
Build.TriggeredBy.ProjectID	Als de build is geactiveerd door een andere build, wordt deze variabele ingesteld op id van het project dat de triggering-build bevat. In klassieke pijplijnen wordt deze variabele geactiveerd door een trigger voor het voltooien van de build. Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag. Als u een YAML-pijplijn activeert met behulp van resources, moet u in plaats daarvan de resourcevariabelen gebruiken.	Nee
Common.TestResultsDirectory	Het lokale pad op de agent waar de testresultaten worden gemaakt. Voorbeeld: c:\agent_work\1\TestResults. Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag.	Nee

Pijplijnvariabelen (DevOps Services)

Variabele	Beschrijving
Pipeline.Workspace	Werkruimtemap voor een bepaalde pijplijn. Deze variabele heeft dezelfde waarde als Agent.BuildDirectory. Bijvoorbeeld: /home/vsts/work/1.

Tip

Als u klassieke release-pijplijnen gebruikt, kunt u klassieke releases en artefactvariabelen gebruiken om gegevens in uw pijplijn op te slaan en te openen.

Variabelen voor implementatietaak (DevOps Services)

Deze variabelen zijn gericht op een specifieke implementatietaak en worden alleen opgelost tijdens de uitvoering van de taak.

Variabele	Beschrijving
Environment.Name	De naam van de omgeving waarop de implementatietaak is gericht om de implementatiestappen uit te voeren en de implementatiegeschiedenis vast te leggen. Bijvoorbeeld: smarthotel-dev.
Environment.Id	Id van de omgeving die is gericht op de implementatietaak. Bijvoorbeeld: 10.
Environment.ResourceName	Naam van de specifieke resource in de omgeving die is gericht op de implementatietaak om de implementatiestappen uit te voeren en de implementatiegeschiedenis vast te leggen. Dit is bijvoorbeeld bookings een Kubernetes-naamruimte die is toegevoegd als een resource aan de omgeving smarthotel-dev.
Environment.ResourceId	Id van de specifieke resource in de omgeving die is gericht in de implementatietaak om de implementatiestappen uit te voeren. Bijvoorbeeld: 4.
Strategy.Name	De naam van de implementatiestrategie: canary, runOnceof rolling.
Strategy.CycleName	De naam van de huidige cyclus in een implementatie. Opties zijn PreIteration, Iterationof PostIteration.

Systeemvariabelen (DevOps Services)

Variabele	Beschrijving	Beschikbaar in sjablonen?
System.AccessToken	Gebruik het OAuth-token om toegang te krijgen tot de REST API. System.AccessToken gebruiken vanuit YAML-scripts. Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag.	Ja
System.CollectionId	De GUID van de TFS-verzameling of Azure DevOps-organisatie.	Ja
System.CollectionUri	De URI van de TFS-verzameling of De Azure DevOps-organisatie. Voorbeeld: https://dev.azure.com/fabrikamfiber/.	Ja
System.DefaultWorkingDirectory	Het lokale pad op de agent waar uw broncodebestanden worden gedownload. Bijvoorbeeld: c:\agent_work\1\s Nieuwe build-pijplijnen werken standaard alleen de gewijzigde bestanden bij. U kunt wijzigen hoe bestanden worden gedownload op het tabblad Opslagplaats. Deze variabele is binnen het bereik van de agent. Het kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag.	Ja
System.DefinitionId	De id van de build-pijplijn.	Ja
System.HostType	Ingesteld op build of de pijplijn een build is. Voor een release zijn deployment de waarden voor een implementatiegroepstaak, gates tijdens de evaluatie van poorten en release voor andere (agent- en agentloze) taken.	Ja
System.JobAttempt	Ingesteld op 1 wanneer deze taak de eerste keer wordt geprobeerd en wordt elke keer dat de taak opnieuw wordt geprobeerd, verhoogd.	Nee
System.JobDisplayName	De door mensen leesbare naam die aan een taak is gegeven.	Nee
System.JobId	Een unieke id voor één poging tot één taak. De waarde is uniek voor de huidige pijplijn.	Nee
System.JobName	De naam van de taak, die doorgaans wordt gebruikt voor het uitdrukken van afhankelijkheden en het openen van uitvoervariabelen.	Nee
System.PhaseAttempt	Stel deze fase in op 1 wanneer deze fase voor het eerst wordt geprobeerd en wordt steeds verhoogd wanneer de taak opnieuw wordt geprobeerd. Opmerking: 'Fase' is een voornamelijk redundant concept, dat de ontwerptijd voor een taak vertegenwoordigt (terwijl de taak de runtimeversie van een fase was). We hebben het concept van 'fase' voornamelijk verwijderd uit Azure Pipelines. Matrix- en multiconfiguratietaken zijn de enige plaats waar 'fase' nog steeds verschilt van 'job'. Eén fase kan meerdere taken instantiëren, die alleen verschillen in hun invoer.	Nee
System.PhaseDisplayName	De door mensen leesbare naam die aan een fase is gegeven.	Nee
System.PhaseName	Een id op basis van tekenreeksen voor een taak, die doorgaans wordt gebruikt voor het uitdrukken van afhankelijkheden en het openen van uitvoervariabelen.	Nee
System.PlanId	Een id op basis van tekenreeksen voor één pijplijnuitvoering.	Nee
System.PullRequest.IsFork	Als de pull-aanvraag afkomstig is van een fork van de opslagplaats, wordt deze variabele ingesteld op True. Anders is deze ingesteld op False.	Ja
System.PullRequest.PullRequestId	De id van de pull-aanvraag die deze build heeft veroorzaakt. Voorbeeld: 17. (Deze variabele wordt alleen geïnitialiseerd als de build is uitgevoerd vanwege een Git PR beïnvloed door een vertakkingsbeleid).	Nee
System.PullRequest.PullRequestNumber	Het aantal pull-aanvragen dat deze build heeft veroorzaakt. Deze variabele wordt ingevuld voor pull-aanvragen van GitHub met een andere pull-aanvraag-id en een ander pull-aanvraagnummer. Deze variabele is alleen beschikbaar in een YAML-pijplijn als de pull-aanvraag wordt beïnvloed door een vertakkingsbeleid.	Nee
System.PullRequest.targetBranchName	De naam van de doelbranch voor een pull-aanvraag. Deze variabele kan in een pijplijn worden gebruikt om taken of stappen voorwaardelijk uit te voeren op basis van de doelbranch van de pull-aanvraag. U kunt bijvoorbeeld een andere set tests of hulpprogramma's voor codeanalyse activeren, afhankelijk van de vertakking waarmee de wijzigingen worden samengevoegd.	Nee
System.PullRequest.SourceBranch	De vertakking die wordt gecontroleerd in een pull-aanvraag. Bijvoorbeeld: refs/heads/users/raisa/new-feature voor Azure-opslagplaatsen. (Deze variabele wordt alleen geïnitialiseerd als de build is uitgevoerd vanwege een Git PR beïnvloed door een vertakkingsbeleid). Deze variabele is alleen beschikbaar in een YAML-pijplijn als de pull-aanvraag wordt beïnvloed door een vertakkingsbeleid.	Nee
System.PullRequest.SourceCommitId	De doorvoering die wordt gecontroleerd in een pull-aanvraag. (Deze variabele wordt alleen geïnitialiseerd als de build is uitgevoerd vanwege een Git PR beïnvloed door een vertakkingsbeleid). Deze variabele is alleen beschikbaar in een YAML-pijplijn als de pull-aanvraag wordt beïnvloed door een vertakkingsbeleid.
System.PullRequest.SourceRepositoryURI	De URL naar de opslagplaats die de pull-aanvraag bevat. Voorbeeld: https://dev.azure.com/ouraccount/_git/OurProject.	Nee
System.PullRequest.TargetBranch	De vertakking die het doel is van een pull-aanvraag. Bijvoorbeeld: refs/heads/main wanneer uw opslagplaats zich in Azure-opslagplaatsen bevindt en main wanneer uw opslagplaats zich in GitHub bevindt. Deze variabele wordt alleen geïnitialiseerd als de build wordt uitgevoerd vanwege een Git-pull-aanvraag die wordt beïnvloed door een vertakkingsbeleid. Deze variabele is alleen beschikbaar in een YAML-pijplijn als de pull-aanvraag wordt beïnvloed door een vertakkingsbeleid.	Nee
System.StageAttempt	Stel deze fase in op 1 wanneer deze fase voor het eerst wordt geprobeerd en wordt steeds verhoogd wanneer de taak opnieuw wordt geprobeerd.	Nee
System.StageDisplayName	De door mensen leesbare naam die aan een fase is gegeven.	Nee
System.StageName	Een tekenreeks-id voor een fase, die doorgaans wordt gebruikt voor het uitdrukken van afhankelijkheden en het openen van uitvoervariabelen.	Nee
System.TeamFoundationCollectionUri	De URI van de TFS-verzameling of De Azure DevOps-organisatie. Voorbeeld: https://dev.azure.com/fabrikamfiber/. Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag.	Ja
System.TeamProject	De naam van het project dat deze build bevat.	Ja
System.TeamProjectId	De id van het project waartoe deze build behoort.	Ja
System.TimelineId	Een tekenreeks-id voor de uitvoeringsdetails en logboeken van één pijplijnuitvoering.	Nee
TF_BUILD	Ingesteld op True of het script wordt uitgevoerd door een build-taak. Deze variabele heeft een agentbereik en kan worden gebruikt als een omgevingsvariabele in een script en als parameter in een build-taak, maar niet als onderdeel van het buildnummer of als een versiebeheertag.	Nee

Variabelen controleren (DevOps Services)

Variabele	Beschrijving
Checks.StageAttempt	Stel deze fase in op 1 wanneer deze fase voor het eerst wordt geprobeerd en wordt verhoogd telkens wanneer de fase opnieuw wordt geprobeerd. Deze variabele kan alleen worden gebruikt binnen een goedkeuring of controle op een omgeving. U kunt bijvoorbeeld een REST API-controle aanroepen.$(Checks.StageAttempt)

Hoe worden de identiteitsvariabelen ingesteld?

De waarde is afhankelijk van wat de build heeft veroorzaakt en specifiek is voor Opslagplaatsen van Azure-opslagplaatsen.

Als de build wordt geactiveerd...	Vervolgens zijn de waarden Build.QueuedBy en Build.QueuedById gebaseerd op...	Vervolgens zijn de waarden Build.RequestedFor en Build.RequestedForId gebaseerd op...
In Git of door ci-triggers (Continuous Integration)	De systeemidentiteit, bijvoorbeeld: [DefaultCollection]\Project Collection Service Accounts	De persoon die de wijzigingen heeft gepusht of ingecheckt.
In Git of door een build voor vertakkingsbeleid.	De systeemidentiteit, bijvoorbeeld: [DefaultCollection]\Project Collection Service Accounts	De persoon die de wijzigingen heeft ingecheckt.
In TFVC door een gated check-in trigger	De persoon die de wijzigingen heeft ingecheckt.	De persoon die de wijzigingen heeft ingecheckt.
In Git of TFVC door de geplande triggers	De systeemidentiteit, bijvoorbeeld: [DefaultCollection]\Project Collection Service Accounts	De systeemidentiteit, bijvoorbeeld: [DefaultCollection]\Project Collection Service Accounts
Omdat u op de knop Wachtrij maken hebt geklikt	U	U