Share via


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

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

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

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.

    Systeemopsporing instellen op 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.Debug true 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)
  • Skipped (laatste taak)
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)

Wanneer u een variabele gebruikt in een sjabloon die niet is gemarkeerd als beschikbaar in sjablonen, wordt de variabele niet weergegeven. De variabele wordt niet weergegeven omdat de waarde ervan niet toegankelijk is binnen het bereik van de sjabloon.

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

Wanneer u een variabele gebruikt in een sjabloon die niet is gemarkeerd als beschikbaar in sjablonen, wordt de variabele niet weergegeven. De variabele wordt niet weergegeven omdat de waarde ervan niet toegankelijk is binnen het bereik van de sjabloon.

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.OidcRequestUri Genereer een idToken for authentication with Entra ID using OpenID Connect (OIDC). Meer informatie. Ja
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)

Voeg de fasepoging toe als parameter.

Agentvariabelen (DevOps Server 2022)

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 'Taak' 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)
  • Skipped (laatste taak)
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 mogelijk verschillende besturingssystemen uitgevoerd op de agenthost en -container.
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"
  }
}

Build-variabelen (DevOps Server 2022)

Wanneer u een variabele gebruikt in een sjabloon die niet is gemarkeerd als beschikbaar in sjablonen, wordt de variabele niet weergegeven. De variabele wordt niet weergegeven omdat de waarde ervan niet toegankelijk is binnen het bereik van de sjabloon.

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 voor meer informatie. Deze variabele is beschikbaar in Azure DevOps Server 2022.1 en hoger. 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?. 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.
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 is8, 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: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.
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 Server 2022)

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 implementatietaken (DevOps Server 2022)

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

Wanneer u een variabele gebruikt in een sjabloon die niet is gemarkeerd als beschikbaar in sjablonen, wordt de variabele niet weergegeven. De variabele wordt niet weergegeven omdat de waarde ervan niet toegankelijk is binnen het bereik van de sjabloon.

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.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 verhoogd telkens wanneer de fase 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 Server 2022)

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)
Voeg de fasepoging toe als parameter.

Agentvariabelen (DevOps Server 2020)

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.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 'Taak' 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)
  • Skipped (laatste taak)
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 ingesteld. Zie agents.
Agent.OS Het besturingssysteem van de agenthost. Geldige waarden zijn:
  • Windows_NT
  • Darwin
  • Linux
Als u in een container werkt, worden mogelijk verschillende besturingssystemen uitgevoerd op de agenthost en -container.
Agent.OSArchitecture De processorarchitectuur van het besturingssysteem van de agenthost. Geldige waarden zijn:
  • X86
  • X64
  • ARM processor
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)

Variabelen bouwen (DevOps Server 2020)

Wanneer u een variabele gebruikt in een sjabloon die niet is gemarkeerd als beschikbaar in sjablonen, wordt de variabele niet weergegeven. De variabele wordt niet weergegeven omdat de waarde ervan niet toegankelijk is binnen het bereik van de sjabloon.

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.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 voor de zelfopslagplaats (primaire) stap geen aangepast uitgecheckt pad is gedefinieerd of als het betalingspad het standaardpad $(Pipeline.Workspace)/s/&lt;RepoName&gt; voor meervoudige betaling is voor de zelfopslagplaats, 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.
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 is8, 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:
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.
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.

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

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

Variabelen voor implementatietaken (DevOps Server 2020)

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.

Systeemvariabelen (DevOps Server 2020)

Wanneer u een variabele gebruikt in een sjabloon die niet is gemarkeerd als beschikbaar in sjablonen, wordt de variabele niet weergegeven. De variabele wordt niet weergegeven omdat de waarde ervan niet toegankelijk is binnen het bereik van de sjabloon.

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 Een verzamelings-URI van Team Foundation Server. 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.
Nee
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.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. Ja
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 die een andere pull-aanvraag-id en een ander pull-aanvraagnummer hebben. 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. Voorbeeld: refs/heads/users/raisa/new-feature. (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.TeamFoundationCollectionUri De URI van de teambasisverzameling. 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
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

Agentvariabelen (DevOps Server 2019)

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. Voorbeeld: c:\agent_work\1.
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 'Taak' 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)
  • Skipped (laatste taak)
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 ingesteld. 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 processor
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.
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.

Deze map is niet gegarandeerd beschrijfbaar door pijplijntaken (bijvoorbeeld wanneer deze is toegewezen aan een container).

Variabelen bouwen (DevOps Server 2019)

Variabele Beschrijving
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 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.
Build.BuildId De id van de record voor de voltooide build.
Build.BuildNumber De naam van de voltooide build. U kunt de indeling van het buildnummer opgeven waarmee deze waarde wordt gegenereerd in de pijplijnopties.

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 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.
Build.BuildUri De URI voor de build. Voorbeeld: vstfs:///Build/Build/1430.

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.
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 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.
Build.DefinitionName De naam van de build-pijplijn.

Opmerking: deze waarde kan spaties of andere ongeldige labeltekens bevatten. In deze gevallen mislukt de labelindeling .
Build.DefinitionVersion De versie van de build-pijplijn.
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 .
Build.QueuedById Zie 'Hoe worden de identiteitsvariabelen ingesteld?' weergegeven.
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.
Zie Build-pijplijntriggers, Codekwaliteit verbeteren met vertakkingsbeleid.
Build.Repository.Clean De waarde die u hebt geselecteerd voor Opschonen in de instellingen van de bronopslagplaats.

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.
Build.Repository.LocalPath 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.

Deze variabele is synoniem voor Build.SourcesDirectory.
Build.Repository.Name De naam van de 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.
Build.Repository.Provider Het type opslagplaats dat u hebt geselecteerd.
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.
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 is8, kan de naam van de werkruimte het volgende zijn: ws_12_8

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.
Build.Repository.Uri De URL voor de opslagplaats. Voorbeeld:
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.
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 .
Build.RequestedForEmail Zie 'Hoe worden de identiteitsvariabelen ingesteld?' weergegeven.
Build.RequestedForId Zie 'Hoe worden de identiteitsvariabelen ingesteld?' weergegeven.
Build.SourceBranch De vertakking 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 u deze variabele gebruikt in de buildnummernotatie, 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.
Build.SourceBranchName De naam van de vertakking 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.
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. 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.

Deze variabele is synoniem voor Build.Repository.LocalPath.
Build.SourceVersion De meest recente versiebeheerwijziging die is opgenomen in deze build.
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.
Build.SourceVersionMessage De opmerking van de doorvoer of wijzigingenset. Het bericht wordt afgekapt tot de eerste regel of 200 tekens, afhankelijk van wat korter is.

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.

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.
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 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.
Build.Repository.Git.SubmoduleCheckout De waarde die u hebt geselecteerd voor uitgecheckte submodules 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.
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.
Build.TriggeredBy.BuildId Als de build is geactiveerd door een andere build, wordt deze variabele ingesteld op de BuildID van de triggerende build.

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.
Build.TriggeredBy.DefinitionId Als de build is geactiveerd door een andere build, wordt deze variabele ingesteld op de DefinitionID van de triggerende build.

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.
Build.TriggeredBy.DefinitionName Als de build is geactiveerd door een andere build, wordt deze variabele ingesteld op de naam van de triggerende build-pijplijn.

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.
Build.TriggeredBy.BuildNumber Als de build is geactiveerd door een andere build, wordt deze variabele ingesteld op het nummer van de triggerende build.

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

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.
Common.TestResultsDirectory Het lokale pad op de agent waar de testresultaten worden gemaakt. Voorbeeld: c:\agent_work\1\TestResults.

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.

Systeemvariabelen (DevOps Server 2019)

PowerShell-voorbeeldscript: toegang tot REST API

Variabele Beschrijving
System.AccessToken Gebruik het OAuth-token om toegang te krijgen tot de REST API.

System.AccessToken gebruiken vanuit YAML-scripts.

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.
System.CollectionId De GUID van de TFS-verzameling of Azure DevOps-organisatie
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.
System.DefinitionId De id van de build-pijplijn.
System.HostType Ingesteld op build of de pijplijn een build is. Voor een release zijn deployment de waarden voor een implementatiegroeptaak en release voor een agenttaak.
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.
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.)
System.PullRequest.PullRequestNumber Het aantal pull-aanvragen dat deze build heeft veroorzaakt. Deze variabele wordt ingevuld voor pull-aanvragen van GitHub, die een andere pull-aanvraag-id en een ander pull-aanvraagnummer hebben.
System.PullRequest.SourceBranch De vertakking die wordt gecontroleerd in een pull-aanvraag. Voorbeeld: refs/heads/users/raisa/new-feature. (Deze variabele wordt alleen geïnitialiseerd als de build is uitgevoerd vanwege een Git PR beïnvloed door een vertakkingsbeleid.)
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.)
System.PullRequest.SourceRepositoryURI De URL naar de opslagplaats die de pull-aanvraag bevat. Voorbeeld: https://dev.azure.com/ouraccount/_git/OurProject. (Deze variabele wordt alleen geïnitialiseerd als de build is uitgevoerd vanwege een Git-pull-aanvraag voor Azure-opslagplaatsen die worden beïnvloed door een vertakkingsbeleid. Het is niet geïnitialiseerd voor GitHub PRs.)
System.PullRequest.TargetBranch De vertakking die het doel is van een pull-aanvraag. Voorbeeld: refs/heads/main. Deze variabele wordt alleen geïnitialiseerd als de build wordt uitgevoerd vanwege een Git-pull-aanvraag die wordt beïnvloed door een vertakkingsbeleid.
System.TeamFoundationCollectionUri De URI van de teambasisverzameling. Voorbeeld: https://dev.azure.com/fabrikamfiber/.

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.
System.TeamProject De naam van het project dat deze build bevat.
System.TeamProjectId De id van het project waartoe deze build behoort.
TF_BUILD Ingesteld op True of het script wordt uitgevoerd door een build-taak.

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.

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