Git- of TFS Git-opslagplaatsen voor Azure-opslagplaatsen bouwen

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

Azure Pipelines kan elke pull-aanvraag automatisch bouwen en valideren en doorvoeren in uw Git-opslagplaats voor Azure-opslagplaatsen.

Kies een opslagplaats om te bouwen

YAML

U maakt een nieuwe pijplijn door eerst een opslagplaats en vervolgens een YAML-bestand in die opslagplaats te selecteren. De opslagplaats waarin het YAML-bestand aanwezig is, wordt opslagplaats genoemd self . Dit is standaard de opslagplaats die door uw pijplijn wordt gebouwd.

U kunt uw pijplijn later configureren om een andere opslagplaats of meerdere opslagplaatsen te bekijken. Als u wilt weten hoe u dit doet, raadpleegt u het uitchecken van meerdere opslagplaatsen.

Klassiek

Als u tijdens het maken van een pijplijn de opslagplaats wilt kiezen die u wilt bouwen, selecteert u eerst het project waartoe de opslagplaats behoort. Selecteer vervolgens de opslagplaats.

Aanvullende opslagplaatsen klonen als onderdeel van uw pijplijn:

• Als de opslagplaats zich in hetzelfde project bevindt als uw pijplijn, of als het toegangstoken (hieronder uitgelegd) toegang heeft tot de opslagplaats in een ander project, gebruikt u de volgende opdracht:

  git clone -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" <clone URL>

  Als u een script wilt gebruiken System.AccessToken , moet u het eerst beschikbaar maken voor het script. Hiervoor selecteert u de taak onder het tabblad Taken in de editor, selecteert u Aanvullende opties in het rechterdeelvenster en schakelt u de optie Scripts toestaan om toegang te krijgen tot het OAuth-token.

• Als het toegangstoken (hieronder uitgelegd) geen toegang heeft tot de opslagplaats:

  1. Een persoonlijk toegangstoken (PAT) ophalen met Code (read) bereik en het voorvoegsel metPAT:
  2. Base64-codeer deze tekenreeks om een basisverificatietoken te maken.
  3. Voeg een script toe aan uw pijplijn met de volgende opdracht om die opslagplaats te klonen git clone -c http.extraheader="AUTHORIZATION: basic <BASIC_AUTH_TOKEN>" <clone URL>

Azure Pipelines moet toegang krijgen tot uw opslagplaatsen om hun builds te activeren en hun code op te halen tijdens builds. Normaal gesproken heeft een pijplijn toegang tot opslagplaatsen in hetzelfde project. Maar als u toegang wilt tot opslagplaatsen in een ander project, moet u de machtigingen bijwerken die zijn verleend aan toegangstokens voor taken.

CI-triggers

Ci-triggers (continue integratie) zorgen ervoor dat een pijplijn wordt uitgevoerd wanneer u een update naar de opgegeven vertakkingen pusht of dat u opgegeven tags pusht.

YAML

YAML-pijplijnen worden standaard geconfigureerd met een CI-trigger op alle vertakkingen, tenzij de instelling impliciete YAML CI-trigger uitschakelen, geïntroduceerd in Azure DevOps sprint 227, is ingeschakeld. De instelling impliciete YAML CI-trigger uitschakelen kan worden geconfigureerd op organisatieniveau of op projectniveau. Wanneer de instelling impliciete YAML CI-trigger uitschakelen is ingeschakeld, worden CI-triggers voor YAML-pijplijnen niet ingeschakeld als de YAML-pijplijn geen sectie heeft trigger . Impliciete YAML CI-trigger uitschakelen is standaard niet ingeschakeld.

Vertakkingen

U kunt bepalen welke vertakkingen CI-triggers ophalen met een eenvoudige syntaxis:

trigger:
- main
- releases/*

U kunt de volledige naam van de vertakking opgeven (bijvoorbeeld main) of een jokerteken (bijvoorbeeld releases/*). Zie Jokertekens voor informatie over de jokertekensyntaxis .

Notitie

U kunt geen variabelen in triggers gebruiken, omdat variabelen tijdens runtime worden geëvalueerd (nadat de trigger is geactiveerd).

Notitie

Als u sjablonen gebruikt om YAML-bestanden te maken, kunt u alleen triggers opgeven in het hoofd-YAML-bestand voor de pijplijn. U kunt geen triggers opgeven in de sjabloonbestanden.

Voor complexere triggers die gebruikmaken exclude van of batchmoet u de volledige syntaxis gebruiken, zoals wordt weergegeven in het volgende voorbeeld.

# specific branch build
trigger:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

In het bovenstaande voorbeeld wordt de pijplijn geactiveerd als een wijziging wordt gepusht naar main of naar een releases-vertakking. Deze wordt echter niet geactiveerd als er een wijziging wordt aangebracht in een releases-vertakking die begint met old.

Als u een exclude component zonder component include opgeeft, is deze gelijk aan het opgeven * in de include component.

Naast het opgeven van vertakkingsnamen in de branches lijsten, kunt u ook triggers configureren op basis van tags met behulp van de volgende indeling:

trigger:
  branches:
    include:
      - refs/tags/{tagname}
    exclude:
      - refs/tags/{othertagname}

Als u geen triggers hebt opgegeven en de instelling impliciete YAML CI-trigger uitschakelen niet is ingeschakeld, is de standaardinstelling alsof u schreef:

trigger:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

Belangrijk

Wanneer u een trigger opgeeft, wordt de standaard impliciete trigger vervangen en wordt alleen gepusht naar vertakkingen die expliciet zijn geconfigureerd om te worden opgenomen, wordt een pijplijn geactiveerd. Insluitingen worden eerst verwerkt en vervolgens worden uitgesloten uit die lijst.

Ci-uitvoeringen batchverwerking

Als u veel teamleden hebt die wijzigingen vaak uploaden, kunt u het aantal uitvoeringen dat u start verminderen. Als u instelt batch op true, wanneer een pijplijn wordt uitgevoerd, wacht het systeem totdat de uitvoering is voltooid en wordt een andere uitvoering gestart met alle wijzigingen die nog niet zijn gebouwd.

# specific branch build with batching
trigger:
  batch: true
  branches:
    include:
    - main

Notitie

batch wordt niet ondersteund in resourcetriggers voor opslagplaatsen.

Om dit voorbeeld te verduidelijken, laten we zeggen dat een push A om de bovenstaande pijplijn uit te main voeren. Terwijl die pijplijn wordt uitgevoerd, worden er extra pushs uitgevoerd B en C deze in de opslagplaats uitgevoerd. Deze updates starten niet onmiddellijk nieuwe onafhankelijke uitvoeringen. Maar nadat de eerste uitvoering is voltooid, worden alle pushes totdat dat tijdstip wordt gebatcheerd en wordt een nieuwe uitvoering gestart.

Notitie

Als de pijplijn meerdere taken en fasen heeft, moet de eerste uitvoering nog steeds een terminalstatus bereiken door alle bijbehorende taken en fasen te voltooien of over te slaan voordat de tweede uitvoering kan worden gestart. Daarom moet u voorzichtig zijn bij het gebruik van deze functie in een pijplijn met meerdere fasen of goedkeuringen. Als u uw builds in dergelijke gevallen wilt batcheren, wordt u aangeraden uw CI/CD-proces op te splitsen in twee pijplijnen: één voor build (met batchverwerking) en één voor implementaties.

Paden

U kunt bestandspaden opgeven die moeten worden opgenomen of uitgesloten.

# specific path build
trigger:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

Wanneer u paden opgeeft, moet u expliciet vertakkingen opgeven waarop moet worden geactiveerd als u Azure DevOps Server 2019.1 of lager gebruikt. U kunt een pijplijn niet activeren met alleen een padfilter; u moet ook een vertakkingsfilter hebben en de gewijzigde bestanden die overeenkomen met het padfilter moeten afkomstig zijn van een vertakking die overeenkomt met het vertakkingsfilter. Als u Azure DevOps Server 2020 of hoger gebruikt, kunt u weglaten branches om te filteren op alle vertakkingen in combinatie met het padfilter.

Wilds-kaarten worden ondersteund voor padfilters. U kunt bijvoorbeeld alle paden opnemen die overeenkomen src/app/**/myapp*. U kunt jokertekens gebruiken (**of *?) bij het opgeven van padfilters).

• Paden worden altijd opgegeven ten opzichte van de hoofdmap van de opslagplaats.
• Als u geen padfilters instelt, wordt de hoofdmap van de opslagplaats impliciet opgenomen.
• Als u een pad uitsluit, kunt u het niet ook opnemen, tenzij u het in aanmerking komt voor een diepere map. Als u bijvoorbeeld /tools uitsluit, kunt u /tools/trigger-runs-on-these opnemen
• De volgorde van padfilters maakt niet uit.
• Paden in Git zijn hoofdlettergevoelig. Zorg ervoor dat u hetzelfde hoofdlettergebruik gebruikt als de echte mappen.
• U kunt geen variabelen in paden gebruiken, omdat variabelen tijdens runtime worden geëvalueerd (nadat de trigger is geactiveerd).

Tags

Naast het opgeven van tags in de branches lijsten zoals beschreven in de vorige sectie, kunt u rechtstreeks tags opgeven die moeten worden opgenomen of uitgesloten:

# specific tag
trigger:
  tags:
    include:
    - v2.*
    exclude:
    - v2.0

Als u geen tagtriggers opgeeft, worden met tags standaard geen pijplijnen geactiveerd.

Belangrijk

Als u tags in combinatie met vertakkingsfilters opgeeft, wordt de trigger geactiveerd als het vertakkingsfilter tevreden is of als het tagfilter is voldaan. Als een gepushte tag bijvoorbeeld voldoet aan het vertakkingsfilter, wordt de pijplijn geactiveerd, zelfs als de tag wordt uitgesloten door het tagfilter, omdat de push tevreden is met het vertakkingsfilter.

Afmelden voor CI

De CI-trigger uitschakelen

U kunt zich volledig afmelden voor CI-triggers door op te trigger: nonegeven.

# A pipeline with no CI trigger
trigger: none

Belangrijk

Wanneer u een wijziging naar een vertakking pusht, wordt het YAML-bestand in die vertakking geëvalueerd om te bepalen of een CI-uitvoering moet worden gestart.

Klassiek

Selecteer Continue integratie inschakelen op het tabblad Triggers om deze trigger in te schakelen als u wilt dat de build wordt uitgevoerd wanneer iemand code incheckt.

Batchwijzigingen

Schakel dit selectievakje in als er veel teamleden wijzigingen vaak uploaden en u het aantal builds dat u uitvoert wilt verminderen. Als u deze optie selecteert wanneer een build wordt uitgevoerd, wacht het systeem totdat de uitvoering is voltooid en wordt vervolgens een andere uitvoering van alle wijzigingen die nog niet zijn gebouwd, in de wachtrij geplaatst.

U kunt batchwijzigingen batchgewijs maken en deze samen bouwen.

Notitie

Als u batchverwerking met een YAML-pijplijn met meerdere fasen gebruikt, moet een uitvoering een terminalstatus bereiken voordat de volgende kan worden gestart. Dit is vaak niet wenselijk omdat een pijplijn met meerdere fasen goedkeuringen en langdurige implementatiefasen kan doorlopen. In deze gevallen wordt u aangeraden een van deze oplossingen te volgen:

• batchverwerking niet gebruiken
• de pijplijn splitsen in twee afzonderlijke pijplijnen: één voor CI en één CD
• de juiste voorwaarden instellen voor fasen om ze over te slaan en een uitvoering snel te beëindigen

Vertakkingsfilters

U kunt de vertakkingen opgeven waar u builds wilt activeren. Als u jokertekens wilt gebruiken, typt u de vertakkingsspecificatie (bijvoorbeeld features/modules/*) en drukt u op Enter.

Padfilters

Als uw Git-opslagplaats zich in Azure-opslagplaatsen of TFS bevindt, kunt u ook padfilters opgeven om de set bestanden te verminderen die u wilt activeren voor een build.

Tips:

• Paden worden altijd opgegeven ten opzichte van de hoofdmap van de opslagplaats.
• Als u geen padfilters instelt, wordt de hoofdmap van de opslagplaats impliciet opgenomen.
• Als u een pad uitsluit, kunt u het niet ook opnemen, tenzij u het in aanmerking komt voor een diepere map. Als u bijvoorbeeld /tools uitsluit, kunt u /tools/trigger-runs-on-these opnemen
• De volgorde van padfilters maakt niet uit.
• Paden in Git zijn hoofdlettergevoelig. Zorg ervoor dat u hetzelfde hoofdlettergebruik gebruikt als de echte mappen.

Opmerking

U wilt bijvoorbeeld dat uw build wordt geactiveerd door wijzigingen in main en de meeste, maar niet alle, van uw functie-vertakkingen. U wilt ook niet dat builds worden geactiveerd door wijzigingen in bestanden in de map hulpprogramma's.

CI voor afzonderlijke pushes overslaan

U kunt Azure Pipelines ook vertellen om het uitvoeren van een pijplijn over te slaan die normaal gesproken door een push wordt geactiveerd. [skip ci] Neem alleen het bericht of de beschrijving op van een van de doorvoeringen die deel uitmaken van een push en Azure Pipelines slaat het uitvoeren van CI voor deze push over. U kunt ook een van de volgende variaties gebruiken.

• [skip ci] of [ci skip]
• skip-checks: true of skip-checks:true
• [skip azurepipelines] of [azurepipelines skip]
• [skip azpipelines] of [azpipelines skip]
• [skip azp] of [azp skip]
• ***NO_CI***

Het triggertype gebruiken in voorwaarden

Het is een veelvoorkomend scenario voor het uitvoeren van verschillende stappen, taken of fasen in uw pijplijn, afhankelijk van het type trigger waarmee de uitvoering is gestart. U kunt dit doen met behulp van de systeemvariabele Build.Reason. Voeg bijvoorbeeld de volgende voorwaarde toe aan uw stap, taak of fase om deze uit te sluiten van pull-validaties.

condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))

Gedrag van triggers wanneer nieuwe vertakkingen worden gemaakt

Het is gebruikelijk om meerdere pijplijnen voor dezelfde opslagplaats te configureren. U hebt bijvoorbeeld één pijplijn om de documenten voor uw app te bouwen en een andere om de broncode te bouwen. U kunt CI-triggers configureren met de juiste vertakkingsfilters en padfilters in elk van deze pijplijnen. U wilt bijvoorbeeld dat één pijplijn wordt geactiveerd wanneer u een update naar de docs map pusht en een andere die moet worden geactiveerd wanneer u een update naar uw toepassingscode pusht. In deze gevallen moet u weten hoe de pijplijnen worden geactiveerd wanneer een nieuwe vertakking wordt gemaakt.

Dit is het gedrag wanneer u een nieuwe vertakking (die overeenkomt met de vertakkingsfilters) naar uw opslagplaats pusht:

• Als uw pijplijn padfilters bevat, wordt deze alleen geactiveerd als de nieuwe vertakking wijzigingen bevat in bestanden die overeenkomen met dat padfilter.
• Als uw pijplijn geen padfilters heeft, wordt deze geactiveerd, zelfs als er geen wijzigingen in de nieuwe vertakking zijn.

Jokertekens

Wanneer u een vertakking, tag of pad opgeeft, kunt u een exacte naam of een jokerteken gebruiken. Jokertekens-patronen maken het * mogelijk om nul of meer tekens overeen te laten komen en ? één teken te vinden.

• Als u uw patroon * in een YAML-pijplijn start, moet u het patroon tussen aanhalingstekens laten teruglopen, zoals "*-releases".
• Voor vertakkingen en tags:
  • Er kan ergens in het patroon een jokerteken worden weergegeven.
• Voor paden:
  • In Azure DevOps Server 2022 en hoger, met inbegrip van Azure DevOps Services, kan een jokerteken overal in een padpatroon worden weergegeven en u kunt dit gebruiken * of ?.
  • In Azure DevOps Server 2020 en lager kunt u het laatste teken opnemen * , maar dit doet niets anders dan het opgeven van de mapnaam zelf. U mag niet * opnemen in het midden van een padfilter en u mag dit niet gebruiken?.

trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

PR-triggers

Pull-aanvraagtriggers zorgen ervoor dat een pijplijn wordt uitgevoerd wanneer u een pull-aanvraag opent of wanneer u wijzigingen naar de pull-aanvraag pusht. In Azure Repos Git wordt deze functionaliteit geïmplementeerd met behulp van vertakkingsbeleid. Als u pull-aanvraagvalidatie wilt inschakelen, gaat u naar het vertakkingsbeleid voor de gewenste vertakking en configureert u het buildvalidatiebeleid voor die vertakking. Zie Vertakkingsbeleid configureren voor meer informatie.

Als u een open pull-aanvraag hebt en u wijzigingen naar de bronbranch pusht, kunnen meerdere pijplijnen worden uitgevoerd:

• De pijplijnen die zijn opgegeven door het buildvalidatiebeleid van de doelbranch worden uitgevoerd op de samenvoegdoorvoering (de samengevoegde code tussen de bron- en doelbranches van de pull-aanvraag), ongeacht of er push-doorvoeringen bestaan waarvan de berichten of beschrijvingen bestaan [skip ci] (of een van de varianten).
• De pijplijnen die worden geactiveerd door wijzigingen in de bronbranch van de pull-aanvraag, als er geen gepushte doorvoeringen zijn waarvan de berichten of beschrijvingen (of een van de varianten ervan) bevatten [skip ci] . Als ten minste één gepushte doorvoer bevat [skip ci], worden de pijplijnen niet uitgevoerd.

Nadat u de pull-aanvraag hebt samengevoegd, worden in Azure Pipelines de CI-pijplijnen uitgevoerd die worden geactiveerd door pushes naar de doelbranch, zelfs als sommige van de samengevoegde doorvoeringen berichten of beschrijvingen bevatten [skip ci] (of een van de varianten).

Notitie

Als u validatie-builds wilt configureren voor een Git-opslagplaats voor Azure-opslagplaatsen, moet u een projectbeheerder van het bijbehorende project zijn.

Notitie

Concept pull-aanvragen activeren geen pijplijn, zelfs niet als u een vertakkingsbeleid configureert.

Bijdragen van forks valideren

Het bouwen van pull-aanvragen van Azure Repos-forks verschilt niet van het bouwen van pull-aanvragen binnen dezelfde opslagplaats of hetzelfde project. U kunt alleen forks maken binnen dezelfde organisatie waarvan uw project deel uitmaakt.

Bereik voor taakautorisatie beperken

Azure Pipelines biedt verschillende beveiligingsinstellingen voor het configureren van het taakautorisatiebereik waarmee uw pijplijnen worden uitgevoerd.

• Bereik van taakautorisatie beperken tot huidig project
• Toegang tot opslagplaatsen in YAML-pijplijnen beveiligen

Bereik van taakautorisatie beperken tot huidig project

Azure Pipelines biedt twee bereik voor taakautorisatie beperken tot de huidige projectinstellingen :

• Bereik van taakautorisatie beperken tot huidig project voor niet-release-pijplijnen : deze instelling is van toepassing op YAML-pijplijnen en klassieke build-pijplijnen. Deze instelling is niet van toepassing op klassieke release-pijplijnen.
• Bereik voor taakautorisatie beperken tot het huidige project voor release-pijplijnen : deze instelling is alleen van toepassing op klassieke release-pijplijnen .

Pijplijnen worden uitgevoerd met toegangstokens met een verzamelingsbereik, tenzij de relevante instelling voor het pijplijntype is ingeschakeld. Met de bereikinstellingen voor taakautorisatie beperken kunt u het toegangsbereik voor alle pijplijnen tot het huidige project beperken. Dit kan van invloed zijn op uw pijplijn als u toegang hebt tot een Git-opslagplaats voor Azure-opslagplaatsen in een ander project in uw organisatie.

Als uw Git-opslagplaats voor Azure-opslagplaatsen zich in een ander project bevindt dan uw pijplijn en de instelling Voor taakautorisatie beperken voor uw pijplijntype is ingeschakeld, moet u toestemming verlenen voor de buildservice-identiteit voor uw pijplijn naar het tweede project. Zie Machtigingen voor buildserviceaccounts beheren voor meer informatie.

Zie Toegangstokens voor taken begrijpen voor meer informatie over het bereik voor taakautorisatie.

Toegang tot opslagplaatsen in YAML-pijplijnen beveiligen

Pijplijnen hebben toegang tot alle Azure DevOps-opslagplaatsen in geautoriseerde projecten, zoals beschreven in het vorige bereik voor taakautorisatie beperken tot de huidige projectsectie , tenzij toegang tot opslagplaatsen in YAML-pijplijnen is ingeschakeld. Als deze optie is ingeschakeld, kunt u het toegangsbereik voor alle pijplijnen beperken tot alleen Azure DevOps-opslagplaatsen waarnaar expliciet wordt verwezen door een checkout stap of een uses instructie in de pijplijntaak die gebruikmaakt van die opslagplaats.

Als u deze instelling wilt configureren, gaat u naar Pijplijnen, Instellingen op Organisatie-instellingen of Project-instellingen. Als deze optie is ingeschakeld op organisatieniveau, wordt de instelling grijs weergegeven en niet beschikbaar op projectinstellingenniveau.

Belangrijk

De toegang tot opslagplaatsen in YAML-pijplijnen beveiligen is standaard ingeschakeld voor nieuwe organisaties en projecten die na mei 2020 zijn gemaakt. Wanneer de toegang tot opslagplaatsen in YAML-pijplijnen beveiligen is ingeschakeld, moeten uw YAML-pijplijnen expliciet verwijzen naar eventuele Git-opslagplaatsen van Azure-opslagplaatsen die u in de pijplijn wilt gebruiken als een uitcheckstap in de taak die gebruikmaakt van de opslagplaats. U kunt geen code ophalen met behulp van scripttaken en Git-opdrachten voor een Git-opslagplaats voor Azure-opslagplaatsen, tenzij er eerst expliciet naar die opslagplaats wordt verwezen.

Er zijn enkele uitzonderingen waarbij u niet expliciet naar een Git-opslagplaats voor Azure-opslagplaatsen hoeft te verwijzen voordat u deze in uw pijplijn gebruikt wanneer de toegang tot opslagplaatsen in YAML-pijplijnen beveiligen is ingeschakeld.

• Als u geen expliciete uitcheckstap in uw pijplijn hebt, is dit alsof u een checkout: self stap hebt en de self opslagplaats is uitgecheckt.
• Als u een script gebruikt om alleen-lezenbewerkingen uit te voeren op een opslagplaats in een openbaar project, hoeft u in een checkout stap niet naar de openbare projectopslagplaats te verwijzen.
• Als u een script gebruikt dat een eigen verificatie voor de opslagplaats biedt, zoals een PAT, hoeft u in een checkout stap niet naar die opslagplaats te verwijzen.

Als bijvoorbeeld de toegang tot opslagplaatsen in YAML-pijplijnen beveiligen is ingeschakeld, als uw pijplijn zich in de FabrikamProject/Fabrikam opslagplaats in uw organisatie bevindt en u een script wilt gebruiken om de FabrikamProject/FabrikamTools opslagplaats uit te checken, moet u in een checkout stap of met een uses instructie naar deze opslagplaats verwijzen.

Als u de opslagplaats in uw FabrikamTools pijplijn al uitcheckt met behulp van een uitcheckstap, kunt u vervolgens scripts gebruiken om met die opslagplaats te communiceren.

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo
# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools
steps:
- script: # Do something with that repo like clone it

Notitie

Voor veel scenario's kan het uitchecken van meerdere opslagplaatsen worden gebruikt, zodat u geen scripts meer hoeft te gebruiken om extra opslagplaatsen in uw pijplijn te bekijken. Zie Meerdere opslagplaatsen in uw pijplijn bekijken voor meer informatie.

Uitchecken

Wanneer een pijplijn wordt geactiveerd, haalt Azure Pipelines uw broncode op uit de Git-opslagplaats van Azure-opslagplaatsen. U kunt verschillende aspecten van hoe dit gebeurt beheren.

Notitie

Wanneer u een uitcheckstap in uw pijplijn opneemt, voeren we de volgende opdracht uit: git -c fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1 Als dit niet aan uw behoeften voldoet, kunt u ervoor kiezen om ingebouwde betaling checkout: none uit te sluiten en vervolgens een scripttaak te gebruiken om uw eigen betaling uit te voeren.

Voorkeursversie van Git

De Windows-agent wordt geleverd met een eigen exemplaar van Git. Als u liever uw eigen Git opgeeft in plaats van de meegeleverde kopie te gebruiken, stelt u deze in System.PreferGitFromPath trueop . Deze instelling geldt altijd voor niet-Windows-agents.

Pad naar uitchecken

YAML

Als u één opslagplaats uitcheckt, wordt uw broncode standaard uitgecheckt in een map met de naam s. Voor YAML-pijplijnen kunt u dit wijzigen door checkout een path. Het opgegeven pad is relatief ten $(Agent.BuildDirectory)opzichte van . Bijvoorbeeld: als de waarde van het uitcheckpad dat is mycustompath en $(Agent.BuildDirectory) is C:\agent\_work\1, wordt de broncode uitgecheckt naar C:\agent\_work\1\mycustompath.

Als u meerdere checkout stappen gebruikt en meerdere opslagplaatsen uitcheckt en niet expliciet de map opgeeft met behulp pathvan, wordt elke opslagplaats in een submap met de naam van s de opslagplaats geplaatst. Als u bijvoorbeeld twee opslagplaatsen met de naam tools uitcheckt en code, wordt de broncode uitgecheckt naar C:\agent\_work\1\s\tools en C:\agent\_work\1\s\code.

Houd er rekening mee dat de waarde van het uitcheckpad niet kan worden ingesteld om de bovenstaande mapniveaus $(Agent.BuildDirectory)op te halen, dus path\..\anotherpath resulteert dit in een geldig betalingspad (dat wil C:\agent\_work\1\anotherpathweten), maar een waarde zoals ..\invalidpath niet (dat wil C:\agent\_work\invalidpathgezegd).

U kunt de path instelling configureren in de stap Uitchecken van uw pijplijn.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Klassiek

Deze instelling kan niet worden geconfigureerd in de klassieke editor. Uw broncode wordt uitgecheckt naar een map met de naam s, die relatief is ten $(Agent.BuildDirectory)opzichte van . Bijvoorbeeld: als $(Agent.BuildDirectory) dat het is C:\agent\_work\1, wordt de broncode uitgecheckt in C:\agent\_work\1\mycustompath.

Submodules

YAML

U kunt de submodules instelling configureren in de stap Uitchecken van uw pijplijn als u bestanden wilt downloaden uit submodules.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Klassiek

U kunt de instelling Submodules configureren vanuit de eigenschappen van de taak Bronnen ophalen in uw pijplijn als u bestanden uit submodules wilt downloaden.

Met de build-pijplijn worden uw Git-submodules uitgecheckt zolang ze:

• Niet-geverifieerd: een openbare, niet-geverifieerde opslagplaats zonder referenties die nodig zijn om te klonen of op te halen.

• Geverifieerde:

  • Dit is opgenomen in hetzelfde project als de Git-opslagplaats voor Azure-opslagplaatsen die hierboven is opgegeven. Dezelfde referenties die door de agent worden gebruikt om de bronnen op te halen uit de hoofdopslagplaats, worden ook gebruikt om de bronnen voor submodules op te halen.

  • Toegevoegd met behulp van een URL ten opzichte van de hoofdopslagplaats. Bijvoorbeeld

    • Deze wordt uitgecheckt: git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

      In dit voorbeeld verwijst de submodule naar een opslagplaats (FabrikamFiber) in dezelfde Azure DevOps-organisatie, maar in een ander project (FabrikamFiberProject). Dezelfde referenties die door de agent worden gebruikt om de bronnen op te halen uit de hoofdopslagplaats, worden ook gebruikt om de bronnen voor submodules op te halen. Hiervoor moet het toegangstoken voor de taak toegang hebben tot de opslagplaats in het tweede project. Als u het toegangstoken voor taken hebt beperkt, zoals uitgelegd in de bovenstaande sectie, kunt u dit niet doen. U kunt het toegangstoken voor de taak toestaan om toegang te krijgen tot de opslagplaats in het tweede project door (a) expliciet toegang te verlenen tot het serviceaccount voor projectbuild in het tweede project of (b) met behulp van toegangstokens binnen het bereik van verzamelingen in plaats van tokens met projectbereik voor de hele organisatie. Zie Access-opslagplaatsen, artefacten en andere resources voor meer informatie over deze opties en de gevolgen voor de beveiliging.

    • Deze zou niet worden uitgecheckt: git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

Alternatief voor het gebruik van de optie Uitchecken-submodules

In sommige gevallen kunt u de optie Submodules uitchecken niet gebruiken. Mogelijk hebt u een scenario waarin een andere set referenties nodig is voor toegang tot de submodules. Dit kan bijvoorbeeld gebeuren als uw hoofdopslagplaats en submoduleopslagplaatsen niet zijn opgeslagen in dezelfde Azure DevOps-organisatie, of als uw taaktoegangstoken geen toegang heeft tot de opslagplaats in een ander project.

Als u de optie Submodules uitchecken niet kunt gebruiken, kunt u in plaats daarvan een aangepaste scriptstap gebruiken om submodules op te halen. Haal eerst een persoonlijk toegangstoken (PAT) op en voorvoegsel met pat:. Vervolgens codeerde base64 deze voorvoegseltekenreeks om een basisverificatietoken te maken. Voeg tot slot dit script toe aan uw pijplijn:

git -c http.https://<url of submodule repository>.extraheader="AUTHORIZATION: Basic <BASE64_ENCODED_STRING>" submodule update --init --recursive

Vervang '<BASE64_ENCODED_STRING>' door de tekenreeks 'pat:token' die is gecodeerd met Base64.

Gebruik een geheime variabele in uw project of build-pijplijn om het basisverificatietoken op te slaan dat u hebt gegenereerd. Gebruik deze variabele om het geheim in de bovenstaande Git-opdracht te vullen.

Notitie

V: Waarom kan ik geen Git-referentiebeheer voor de agent gebruiken? Een: Het opslaan van de submodulereferenties in een Git-referentiebeheerder die is geïnstalleerd op uw privé-buildagent is meestal niet effectief, omdat de referentiebeheerder u mogelijk vraagt om de referenties opnieuw in te voeren wanneer de submodule wordt bijgewerkt. Dit is niet wenselijk tijdens geautomatiseerde builds wanneer gebruikersinteractie niet mogelijk is.

Tags synchroniseren

Belangrijk

De functie synchronisatietags wordt ondersteund in Azure Repos Git met Azure DevOps Server 2022.1 en hoger.

De stap uitchecken maakt gebruik van de optie bij het --tags ophalen van de inhoud van een Git-opslagplaats. Dit zorgt ervoor dat de server alle tags en alle objecten ophaalt waarnaar deze tags worden verwezen. Dit verhoogt de tijd voor het uitvoeren van de taak in een pijplijn, met name als u een grote opslagplaats met een aantal tags hebt. Bovendien synchroniseert de kassastap tags zelfs wanneer u de ondiepe ophaaloptie inschakelt, waardoor het doel mogelijk wordt verslagen. Om de hoeveelheid opgehaalde of opgehaalde gegevens uit een Git-opslagplaats te verminderen, heeft Microsoft een nieuwe optie toegevoegd om het gedrag van synchronisatietags te beheren. Deze optie is zowel beschikbaar in klassieke als YAML-pijplijnen.

Of tags moeten worden gesynchroniseerd bij het uitchecken van een opslagplaats, kan worden geconfigureerd in YAML door de eigenschap in te fetchTags stellen en in de gebruikersinterface door de instelling Labels synchroniseren te configureren.

YAML

U kunt de fetchTags instelling configureren in de stap Uitchecken van uw pijplijn.

Als u de instelling in YAML wilt configureren, stelt u de fetchTags eigenschap in.

steps:
- checkout: self
  fetchTags: true

U kunt deze instelling ook configureren met behulp van de optie Labels synchroniseren in de gebruikersinterface voor pijplijninstellingen.

1. Bewerk uw YAML-pijplijn en kies Meer acties, Triggers.

   

2. Kies YAML, Bronnen ophalen.

   

3. Configureer de instelling Synchronisatietags .

   

Notitie

Als u expliciet in uw checkout stap hebt ingesteldfetchTags, heeft die instelling voorrang op de instelling die is geconfigureerd in de gebruikersinterface voor pijplijninstellingen.

Klassiek

U kunt de instelling Labels synchroniseren configureren vanuit de eigenschappen van de taak Bronnen ophalen in uw pijplijn.

Standaardgedrag

• Voor bestaande pijplijnen die zijn gemaakt vóór de release van Azure DevOps sprint 209, uitgebracht in september 2022, blijft de standaardwaarde voor het synchroniseren van tags hetzelfde als het bestaande gedrag voordat de opties voor synchronisatietags zijn toegevoegd. Dit is true.
• Voor nieuwe pijplijnen die zijn gemaakt na release 209 van Azure DevOps sprint, is falsede standaardinstelling voor het synchroniseren van tags.

Notitie

Als u expliciet in uw checkout stap hebt ingesteldfetchTags, heeft die instelling voorrang op de instelling die is geconfigureerd in de gebruikersinterface voor pijplijninstellingen.

Ondiep ophalen

Mogelijk wilt u beperken hoe ver terug in de geschiedenis moet worden gedownload. Dit resulteert effectief in git fetch --depth=n. Als uw opslagplaats groot is, kan deze optie uw build-pijplijn efficiënter maken. Uw opslagplaats kan groot zijn als deze al lange tijd in gebruik is en een grote geschiedenis heeft. Het kan ook groot zijn als u grote bestanden hebt toegevoegd en later hebt verwijderd.

Belangrijk

Nieuwe pijplijnen die zijn gemaakt na de Azure DevOps sprint 209-update van september 2022, hebben Ondiep ophalen standaard ingeschakeld en geconfigureerd met een diepte van 1. Voorheen was de standaardwaarde niet ondiep ophalen. Als u de pijplijn wilt controleren, bekijkt u de instelling Voor ondiep ophalen in de gebruikersinterface voor pijplijninstellingen, zoals beschreven in de volgende sectie.

YAML

U kunt de fetchDepth instelling configureren in de stap Uitchecken van uw pijplijn.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

U kunt ook diepte voor ophalen configureren door de optie Ondiepe diepte in de gebruikersinterface van de pijplijninstellingen in te stellen.

1. Bewerk uw YAML-pijplijn en kies Meer acties, Triggers.

   

2. Kies YAML, Bronnen ophalen.

   

3. Configureer de instelling Voor ondiep ophalen . Schakel Ondiep ophalen uit om ondiep ophalen uit te schakelen of schakel het selectievakje in en voer een diepte in om ondiep ophalen mogelijk te maken.

   

Notitie

Als u expliciet in uw checkout stap hebt ingesteldfetchDepth, heeft die instelling voorrang op de instelling die is geconfigureerd in de gebruikersinterface voor pijplijninstellingen. Instelling fetchDepth: 0 haalt alle geschiedenis op en overschrijft de instelling Ondiep ophalen .

Klassiek

U kunt de instelling Ondiep ophalen configureren op basis van de eigenschappen van de taak Bronnen ophalen in uw pijplijn.

In deze gevallen kunt u met deze optie netwerk- en opslagbronnen besparen. Het kan ook tijd besparen. De reden waarom het niet altijd tijd bespaart, is omdat in sommige situaties de server mogelijk tijd moet besteden aan het berekenen van de doorvoeringen die moeten worden gedownload voor de diepte die u opgeeft.

Notitie

Wanneer de pijplijn wordt gestart, wordt de vertakking om te bouwen omgezet in een doorvoer-id. Vervolgens haalt de agent de vertakking op en controleert de gewenste doorvoering. Er is een klein venster tussen wanneer een vertakking wordt omgezet in een doorvoer-id en wanneer de agent het uitchecken uitvoert. Als de vertakking snel wordt bijgewerkt en u een zeer kleine waarde instelt voor ondiep ophalen, bestaat de doorvoer mogelijk niet wanneer de agent deze probeert te controleren. Als dat gebeurt, verhoogt u de instelling voor ondiepe ophaaldiepte.

Bronnen niet synchroniseren

Mogelijk wilt u het ophalen van nieuwe doorvoeringen overslaan. Deze optie kan handig zijn in gevallen waarin u het volgende wilt doen:

• Git init, configuratie en ophalen met uw eigen aangepaste opties.

• Gebruik een build-pijplijn om alleen automatisering uit te voeren (bijvoorbeeld sommige scripts) die niet afhankelijk zijn van code in versiebeheer.

YAML

U kunt de instelling Synchronisatiebronnen niet configureren in de stap Uitchecken van uw pijplijn door de instelling in te stellencheckout: none.

steps:
- checkout: none  # Don't sync sources

Klassiek

Selecteer de instelling Bronnen niet synchroniseren in de eigenschappen van de taak Bronnen ophalen in uw pijplijn.

Notitie

Wanneer u deze optie gebruikt, slaat de agent ook de uitvoering van Git-opdrachten over die de opslagplaats opschonen.

Schone build

U kunt verschillende vormen van het opschonen van de werkmap van uw zelf-hostende agent uitvoeren voordat een build wordt uitgevoerd.

Over het algemeen moet u de opslagplaats niet opschonen voor snellere prestaties van uw zelf-hostende agents. Als u in dit geval de beste prestaties wilt krijgen, moet u ervoor zorgen dat u ook incrementeel bouwt door de optie Opschonen uit te schakelen van de taak of het hulpprogramma dat u gebruikt om te bouwen.

Als u de opslagplaats moet opschonen (bijvoorbeeld om problemen te voorkomen die worden veroorzaakt door restbestanden uit een eerdere build), vindt u de onderstaande opties.

Notitie

Schoonmaken is niet effectief als u een door Microsoft gehoste agent gebruikt, omdat u elke keer een nieuwe agent krijgt.

YAML

U kunt de clean instelling configureren in de stap Uitchecken van uw pijplijn.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Wanneer clean deze is ingesteld op true de build-pijplijn, worden wijzigingen in $(Build.SourcesDirectory)de build-pijplijn ongedaan maken. Meer specifiek worden de volgende Git-opdrachten uitgevoerd voordat de bron wordt opgehaald.

git clean -ffdx
git reset --hard HEAD

Voor meer opties kunt u de workspace instelling van een taak configureren.

jobs:
- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  ...
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

Dit biedt de volgende schone opties.

• uitvoer: Dezelfde bewerking als de schone instelling die wordt beschreven in de vorige uitchecktaak, plus: Verwijdert en maakt opnieuw$(Build.BinariesDirectory). Houd er rekening mee dat de $(Build.ArtifactStagingDirectory) en $(Common.TestResultsDirectory) altijd worden verwijderd en opnieuw worden gemaakt vóór elke build, ongeacht een van deze instellingen.

• resources: verwijdert en maakt deze $(Build.SourcesDirectory)opnieuw. Dit resulteert in het initialiseren van een nieuwe, lokale Git-opslagplaats voor elke build.

• alle: verwijdert en maakt opnieuw $(Agent.BuildDirectory). Dit resulteert in het initialiseren van een nieuwe, lokale Git-opslagplaats voor elke build.

Klassiek

Selecteer de instelling Opschonen in de eigenschappen van de taak Bronnen ophalen in uw pijplijn en selecteer een van de volgende opties.

• Bronnen: De build-pijplijn voert een ongedaan maken van wijzigingen in $(Build.SourcesDirectory). Meer specifiek worden de volgende Git-opdrachten uitgevoerd voordat de bron wordt opgehaald.

  git clean -ffdx
  git reset --hard HEAD
  

• Bronnen en uitvoermap: Dezelfde bewerking als de bovenstaande optie Bronnen , plus: Verwijdert en maakt opnieuw $(Build.BinariesDirectory). Houd er rekening mee dat de $(Build.ArtifactStagingDirectory) en $(Common.TestResultsDirectory) altijd worden verwijderd en opnieuw worden gemaakt vóór elke build, ongeacht een van deze instellingen.

• Bronmap: Verwijdert en maakt deze $(Build.SourcesDirectory)opnieuw. Dit resulteert in het initialiseren van een nieuwe, lokale Git-opslagplaats voor elke build.

• Alle buildmappen: verwijdert en maakt deze $(Agent.BuildDirectory)opnieuw. Dit resulteert in het initialiseren van een nieuwe, lokale Git-opslagplaats voor elke build.

Labelbronnen

U kunt uw broncodebestanden labelen om uw team in staat te stellen eenvoudig te bepalen welke versie van elk bestand is opgenomen in de voltooide build. U kunt ook opgeven of de broncode moet worden gelabeld voor alle builds of alleen voor geslaagde builds.

YAML

U kunt deze instelling momenteel niet configureren in YAML, maar wel in de klassieke editor. Wanneer u een YAML-pijplijn bewerkt, hebt u toegang tot de klassieke editor door triggers te kiezen in het menu van de YAML-editor.

Kies YAML in de klassieke editor, kies de taak Bronnen ophalen en configureer vervolgens de gewenste eigenschappen daar.

Klassiek

U kunt de instelling Tagbronnen configureren vanuit de eigenschappen van de taak Bronnen ophalen in uw pijplijn.

In de tagindeling kunt u door de gebruiker gedefinieerde en vooraf gedefinieerde variabelen gebruiken die een bereik van 'Alle' hebben. Bijvoorbeeld:

$(Build.DefinitionName)_$(Build.DefinitionVersion)_$(Build.BuildId)_$(Build.BuildNumber)_$(My.Variable)

De eerste vier variabelen zijn vooraf gedefinieerd. My.Variable kan door u worden gedefinieerd op het tabblad Variabelen.

De build-pijplijn labelt uw bronnen met een Git-tag.

Sommige buildvariabelen kunnen een waarde opleveren die geen geldig label is. Variabelen zoals $(Build.RequestedFor) en $(Build.DefinitionName) kunnen bijvoorbeeld witruimte bevatten. Als de waarde witruimte bevat, wordt de tag niet gemaakt.

Nadat de bronnen zijn gelabeld door uw build-pijplijn, wordt er automatisch een artefact met de Git-ref refs/tags/{tag} toegevoegd aan de voltooide build. Dit geeft uw team extra traceerbaarheid en een meer gebruiksvriendelijke manier om van de build naar de code te navigeren die is gebouwd. De tag wordt beschouwd als een build-artefact omdat deze wordt geproduceerd door de build. Wanneer de build handmatig of via een bewaarbeleid wordt verwijderd, wordt de tag ook verwijderd.

Veelgestelde vragen

Problemen met betrekking tot de integratie van Azure-opslagplaatsen vallen in drie categorieën:

• Mislukte triggers: Mijn pijplijn wordt niet geactiveerd wanneer ik een update naar de opslagplaats push.
• Uitchecken mislukt: Mijn pijplijn wordt geactiveerd, maar mislukt in de stap voor uitchecken.
• Verkeerde versie: Mijn pijplijn wordt uitgevoerd, maar er wordt een onverwachte versie van de bron/YAML gebruikt.

Mislukte triggers

Ik heb zojuist een nieuwe YAML-pijplijn gemaakt met CI/PR-triggers, maar de pijplijn wordt niet geactiveerd.

Volg deze stappen om problemen met uw mislukte triggers op te lossen:

• Worden uw YAML CI- of PULL-triggers overschreven door pijplijninstellingen in de gebruikersinterface? Kies tijdens het bewerken van uw pijplijn ... en vervolgens Triggers.

  

  Controleer de YAML-trigger van hieruit negeren voor de typen triggers (continue integratie of validatie van pull-aanvragen) die beschikbaar zijn voor uw opslagplaats.

  

• Configureert u de PULL-trigger in het YAML-bestand of in vertakkingsbeleidsregels voor de opslagplaats? Voor een Git-opslagplaats voor Azure-opslagplaatsen kunt u geen PULL-trigger configureren in het YAML-bestand. U moet vertakkingsbeleid gebruiken.

• Is uw pijplijn onderbroken of uitgeschakeld? Open de editor voor de pijplijn en selecteer Vervolgens Instellingen om te controleren. Als uw pijplijn is onderbroken of uitgeschakeld, werken triggers niet.

• Hebt u het YAML-bestand in de juiste vertakking bijgewerkt? Als u een update naar een vertakking pusht, bepaalt het YAML-bestand in diezelfde vertakking het CI-gedrag. Als u een update naar een bronbranch pusht, bepaalt het YAML-bestand dat het gevolg is van het samenvoegen van de bronbranch met de doelbranch het gedrag van de pull-aanvraag. Zorg ervoor dat het YAML-bestand in de juiste vertakking de benodigde CI- of PR-configuratie heeft.

• Hebt u de trigger correct geconfigureerd? Wanneer u een YAML-trigger definieert, kunt u zowel component opnemen als uitsluiten voor vertakkingen, tags en paden opgeven. Zorg ervoor dat de include-component overeenkomt met de details van uw doorvoer en dat de exclude-component deze niet uitsluit. Controleer de syntaxis voor de triggers en controleer of deze juist is.

• Hebt u variabelen gebruikt bij het definiëren van de trigger of de paden? Dat wordt niet ondersteund.

• Hebt u sjablonen gebruikt voor uw YAML-bestand? Als dit het geval is, moet u ervoor zorgen dat uw triggers zijn gedefinieerd in het hoofd-YAML-bestand. Triggers die in sjabloonbestanden zijn gedefinieerd, worden niet ondersteund.

• Hebt u de vertakkingen of paden waarnaar u uw wijzigingen hebt gepusht uitgesloten? Test door een wijziging naar een opgenomen pad in een opgenomen vertakking te pushen. Houd er rekening mee dat paden in triggers hoofdlettergevoelig zijn. Zorg ervoor dat u dezelfde case gebruikt als die van echte mappen bij het opgeven van de paden in triggers.

• Heb je net een nieuwe vertakking gepusht? Zo ja, dan start de nieuwe vertakking mogelijk geen nieuwe uitvoering. Zie de sectie 'Gedrag van triggers wanneer nieuwe vertakkingen worden gemaakt'.

Mijn CI- of PR-triggers werken prima. Maar ze werkten nu niet meer.

Voer eerst de stappen voor probleemoplossing in de vorige vraag uit. Voer vervolgens de volgende aanvullende stappen uit:

• Hebt u samenvoegingsconflicten in uw pull-aanvraag? Voor een pull-aanvraag die geen pijplijn heeft geactiveerd, opent u deze en controleert u of er een samenvoegingsconflict is opgetreden. Los het samenvoegingsconflict op.

• Ondervindt u een vertraging bij het verwerken van push- of pull-gebeurtenissen? U kunt dit meestal controleren door te zien of het probleem specifiek is voor één pijplijn of gebruikelijk is voor alle pijplijnen of opslagplaatsen in uw project. Als een push- of PULL-update naar een van de opslagplaatsen dit symptoom vertoont, kunnen er vertragingen optreden bij het verwerken van de updategebeurtenissen. Controleer of er een servicestoring op onze statuspagina optreedt. Als op de statuspagina een probleem wordt weergegeven, moet het team al aan het werk zijn. Controleer regelmatig de pagina op updates over het probleem.

Ik wil niet dat gebruikers de lijst met vertakkingen voor triggers overschrijven wanneer ze het YAML-bestand bijwerken. Hoe kan ik dat doen?

Gebruikers met machtigingen voor het bijdragen van code kunnen het YAML-bestand bijwerken en extra vertakkingen opnemen/uitsluiten. Als gevolg hiervan kunnen gebruikers hun eigen functie of gebruikersbranch opnemen in hun YAML-bestand en die update naar een functie of gebruikersbranch pushen. Dit kan ertoe leiden dat de pijplijn wordt geactiveerd voor alle updates voor die vertakking. Als u dit gedrag wilt voorkomen, kunt u het volgende doen:

1. Bewerk de pijplijn in de gebruikersinterface van Azure Pipelines.
2. Navigeer naar het menu Triggers .
3. Selecteer Hier de YAML-trigger voor continue integratie overschrijven.
4. Geef de vertakkingen op die moeten worden opgenomen of uitgesloten voor de trigger.

Wanneer u deze stappen uitvoert, worden eventuele CI-triggers die zijn opgegeven in het YAML-bestand genegeerd.

Ik heb meerdere opslagplaatsen in mijn YAML-pijplijn. Hoe kan ik triggers voor elke opslagplaats instellen?

Zie triggers in Meerdere opslagplaatsen gebruiken.

Uitchecken mislukt

Ik zie de volgende fout in het logboekbestand tijdens het uitchecken. Hoe los ik dit op?

remote: TF401019: The Git repository with name or identifier XYZ does not exist or you do not have permissions for the operation you are attempting.
fatal: repository 'XYZ' not found
##[error] Git fetch failed with exit code: 128

Volg elk van deze stappen om problemen met de mislukte betaling op te lossen:

• Bestaat de opslagplaats nog? Controleer eerst of dit gebeurt door deze te openen op de pagina Opslagplaatsen .

• Hebt u toegang tot de opslagplaats met behulp van een script? Als dit het volgende is, controleert u het bereik voor taakautorisatie beperken naar de instelling azure DevOps-opslagplaatsen . Wanneer het bereik voor taakautorisatie beperken tot waarnaar wordt verwezen in Azure DevOps-opslagplaatsen is ingeschakeld, kunt u Git-opslagplaatsen van Azure-opslagplaatsen met behulp van een script niet uitchecken, tenzij ze expliciet eerst in de pijplijn worden verwezen.

• Wat is het bereik voor taakautorisatie van de pijplijn?

  • Als het bereik verzameling is:

    • Dit kan een onregelmatige fout zijn. Voer de pijplijn opnieuw uit.
    • Iemand heeft mogelijk de toegang tot het buildserviceaccount van Project Collection verwijderd.
      • Ga naar Project-instellingen voor het project waarin de opslagplaats bestaat. Selecteer Opslagplaatsen > die specifiek zijn voor opslagplaatsen >en vervolgens Beveiliging.
      • Controleer of de Build-service van Project Collection (uw-verzamelingsnaam) bestaat in de lijst met gebruikers.
      • Controleer of dat account een tag maken en leestoegang heeft.

  • Als het bereik project is:

    • Bevindt de opslagplaats zich in hetzelfde project als de pijplijn?
      • Ja:
        • Dit kan een onregelmatige fout zijn. Voer de pijplijn opnieuw uit.
        • Iemand heeft mogelijk de toegang tot het Project Build Service-account verwijderd.
          • Ga naar Project-instellingen voor het project waarin de opslagplaats bestaat. Selecteer Opslagplaatsen > die specifiek zijn voor opslagplaatsen >en vervolgens Beveiliging.
          • Controleer of de buildservice voor uw projectnaam (uw-verzamelingsnaam) bestaat in de lijst met gebruikers.
          • Controleer of dat account een tag maken en leestoegang heeft.
      • Nee:
        • Bevindt uw pijplijn zich in een openbaar project?
          • Ja: U hebt geen toegang tot resources buiten uw openbare project. Maak het project privé.
          • Nee: u moet machtigingen configureren voor toegang tot een andere opslagplaats in dezelfde projectverzameling.

Verkeerde versie

Er wordt een verkeerde versie van het YAML-bestand gebruikt in de pijplijn. Waarom is dat?

• Voor CI-triggers wordt het YAML-bestand dat zich in de vertakking bevindt die u pusht geëvalueerd om te zien of een CI-build moet worden uitgevoerd.
• Voor PULL-triggers wordt het YAML-bestand dat voortvloeit uit het samenvoegen van de bron- en doelbranches van de pull-aanvraag geëvalueerd om te zien of een PULL-build moet worden uitgevoerd.

Verwante artikelen:

• Geplande triggers
• Voltooiingstriggers voor pijplijn